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(54) Wireless communication device with markup language based man-machine interface 



(57) A system, method, and software product pro- 
vide a wireless communications device with a markup 
language based man-machine Interface. The man-ma- 
chine interface provides a user interface for the various 
telecommunications functionality of the wireless com- 
munication device, including dialing telephone num- 
bers, answering telephone calls, creating messages, 
sending messages, receiving messages, establishing 
configuration settings, which is defined in markup lan- 
guage, such as HTML, and accessed through a browser 
program executed by the wireless communication de- 
vice. This feature enables direct access to Internet and 
World Wide Web content, such as Web pages, to be di- 
rectly integrated with telecommunication functions of 
the device, and allows Web content to be seamlessly 
integrated with other types of data, since all data pre- 
sented to the user via the user interface is presented via 
markup language-based pages. The browser process- 
es an extended form of HTML that provides new tabs 
and attributes that enhance the navigational, logical, 
and display capabilities of conventional HTML, and par- 
ticularly adapt HTML to be displayed and used on wire- 
less communication devices with small screen displays. 
The wireless communication device includes the brows- 
er, a set of portable components, and portability layer. 
The browser includes protocol handlers, which imple- 
ment different protocols for accessing various functions 
of the wireless communication device, and content han- 
dlers, which implement various content display mecha- 



nisms for fetching and outputting content on a screen 
display. 
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Description 
BACKGROUND 

5 Field of Invention 

[0001] This invention relates to man-machine interfaces for wireless communication devices, and more particularly, 
to man-machine interfaces constructed from markup languages. 

'0 Background of the Invention 

[0002] Wireless communication devices are becoming an increasingly prevalent for personal communication needs. 
These devices include, for example, cellular telephones, alphanumeric, pagers, "palmtop" computers and personal 
information managers (PIMS), and other small, primarily handheld communication and computing devices. Wireless 

15 communication devices have matured considerably in their features, and now support not only basic point-to-point 
communication functions like telephone calling, but more advanced communications functions, such as electronic mail, 
facsimile receipt and transmission, Internet access and browsing of the World Wide Web, and the like. 
[0003] Generally, wireless communication devices have software that manage various handset functions and the 
telecommunications connection to the base station. The software that manages all the telephony functions is typically 

?o referred to as the telephone stack, and the software that manages the screen display and processes user inputs of 
key presses is referred to as the Man- Machine- Interface or "MMI." The MMI is the topmost, and most visible layer of 
the wireless communication devk:e's software. 

[0004] Because wireless communication devices have generally reached a very desirable and small form factor, the 
primary determinant of a successful device will likely be in its feature set and its ease of use. Thus, the ability to quickly 
?5 design, test, and deliver wireless communication devices that are both easy to use, and have a rich set of features- 
attributes that are often opposed to one another— will be essential to successful product performance. 
[0005] However, wireless communication devices present a variety of more challenging design and implementation 
issues that do not arise with larger processor-based systems, such as notebook and desktop computers, which may 
also have similar telecommunication features. These design challenges include the design of the user interface, the 
customization of the devices for particular service operators, the integration of Intemet and Wortd Wide Web access 
with other communication functionality, and the software development process. 

User Interface Design Constraints 

5 [0006] Unlike desktop and notebook computers, wireless communication devices have a form factor which requires 
a very small screen display size. Desktop computers typically have displays with at least 14" screen size, and resolution 
typically between 640x480 and 1024x768 pixels. In contrast, wireless communication devices typically have a screen 
size between 25x25mm and 80x1 20mm, and resolutions between 90x60 to 120x120 pixels, or about 3-8% of the size 
of the desktop or notebook screen. As a direct result, the user interface design of the wireless communication device 

0 must provide access to essentially the same features as desktop computers, such as electronic mail, facsimiles, and 
Web browsing, yet with only a fraction of the screen area for displaying text, images, kx>ns, and the like. This problem 
of constructing the user Interface to provide these features is particularly significant when handling Web based content, 
since conventional Web content^ such as forms, assume the larger screen size of conventional desktop computers. 
Displaying such forms on the small screen of a wireless communication device results in jumbled and difficult to use 



[0007] Another user interface limitation of wireless communication devices is the severely restricted set of inputs 
available to the user. Conventional desktop or notebook computers have cursor based pointing devices, such as com- 
puter mouse, trackballs, joysticks, and the like, and full keyboard. This enables navigation of Web content by clicking 
and dragging of scroll bars, clicking of hypertext links, and keyboard tabbing between fields of forms, such as HTML 
so forms. Wireless communication devices have a very limited number of inputs, typbally up and down keys, and one to 
three softkeys. 

[0008] Accordingly, It is desirable to provide a software architecture for the MMI of a wireless communication device 
that enables the customization and use of user interface with Web content accounting for the limited screen resolution 
and input functionality of the wireless communication device. 

55 

Integration of Internet/Web Functional with Telephony 

[0009] With the advent of the intemet and the Worid Wide Web, the highest performance wireless communication 
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devices provide complete Internet access and the ability to directly browse the World Wide Web. Current devices 
provide Internet and World Wide Web access through a strictly modal interface, in which the user must select between 
using the wireless communication device in a browser mode in Its native telecommunications mode for making tele- 
phone calls, accessing a stored telephone book, sending facsimiles, and the like. In the "browser mode" the user cannot 
5 dial a telephone number to make a telephone; likewise in the telephony mode, the user cannot access a Web site- 
Thus, the user is unable to operate the wireless communication device in a seamless fashion that allows Web content 
to be downloaded and manipulated in context of the telephone functions, such as embedding an item of Web content 
that is obtained while browsing into the user's telephone book, or into an email message. 

[0010] Accordingly, it is desirable to provide an MM I in which Internet and World Wide Web access features are 
10 seamlessly integrated with the telephony and other controls of the wireless communication device so that user can 
access any feature of the wireless communication device at any time. 

Software Engineering of the MMI 

15 [0011] Typically, an MMI is Implemented as a module in a larger piece of code that manages the telephone control 
functions. The MMI is coded in the same computer language as the rest of the telephone control software. This makes 
the MMI difficult to modify without using the same programming skills and tools used to create the entire telephone 
control software. In other words, changing anything in the MMI requires the services of a skilled programmer familiar 
with the underlying telephony programming details and computer language. In addition, since the MMI is an integral 

^0 part of the code for the telephone control software, Implementing new changes in the MMI means compiling a new 
image of all the telephone control software, and testing the result to ensure that the new MMI features are compatible 
with all other code modules. In short, problems introduced by modifying the MMI software can potentially cause the 
handset to malfunction, disrupting service on the network to other users. Depending on the extent of the modifications, 
the change of any portion of the telephone control software can result in bugs, and/or the need for new type approval 

25 of the entire wireless communication device. Thus, it is desirable to provide a software architecture which separates 
the design and implementation of the MMI functionality from the implementation of the telephone control software, 
allowing the manufacturer to quickly and safely customize the MMI design to suit the needs of a particular customer 

Customizing of the MMI for Service Operators: "Branding" 



[0012] In the wireless communication device industry, the services operators, such as cellular service providers, are 
Interested in attracting and retaining their customers by aggressively branding their wireless communication device 
products, and offering new telephony features and network services to the user. Important among these are services 
that add value to the user, such as voice mail, electronic messaging, Internet access, and the like as mentioned above. 
35 "Branding" is the embedding of insignia, logos, or other indicia into the MMI of the wireless communication device and 
its features that identifies it to the consumer as originating from the service operator. 

[0013] The manufacturers of the wireless communication device, who typically provide only the basic hardware com- 
ponents, must therefore provide a way for the service operator to integrate these features and services Into the wireless 
communication device by software programming, and provide a mechanism for branding the features. A key problem 
to is that these services are necessarily different in their functionality and requirements, and the task of providing users 
with a current array of services and features a difficult one. 

[0014] Wireless communication device manufacturers have traditionally attacked this problem by making a special 
version of the wireless communication device control software for each service operator selling that wireless commu- 
nication device in conjunction with its own communication services. Each specific version of the wireless communication 

'5 device contains the device manufacturer's branding, the operator's branding, and support for whatever features and 
services the service operator supports. Each of these versions becomes a different piece of software to be tested, 
maintained, and modified as new features or services are provided to the consumer. This significantly Increases the 
software development expense and maintenance Issues. Further, unless the wireless communication device manu- 
facturer provides the service operator with the source code of the MMI and telephone control software, it requires the 

0 wireless communication device manufacturer to be directly involved in the branding and MMI design requirements of 
the service operator. Thus, it desirable to provide a software architecture for an MMI that allows the wireless commu- 
nication device manufacturer to provide a single body of telephone control software to each service operator, and 
allows each service operator to independently, and without the assistance of the wireless communication device man- 
ufacturer, design, implement, and brand the MMI for the wireless communication device. 

5 [0015] One system for accessing the world wide web through a wireless cellular phone is described in "Compact 
HTML for Small Information Appliances" (W3C NOTE 09-Feb-1998) submitted by Tomihisa Kamada of Access Co., 
Ltd. This document suggests that cellular phones may use "Compact HTML" for accessing the Intemet. The "Compact 
HTML" proposed defines a subset of HTML for small information appliances such as smart phones, smart communi- 
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cators, mobile PDAs, etc, and excludes features such as JPEG images, tables, frames and other functions which 
require high resolution screens or a large memory to implement. 

SUMMARY OF THE INVENTION 



[0016] According to a first embodiment of the present invention, there is provided a browser program product for 
controlling the operation of a wireless communication device by execution of the browser by a processor of the wireless 
communication device and displaying a page of markup language data, the browser executing the operations of: re- 
ceiving a markup language page including a plurality of hyperlinks; selecting a hyperlink of the markup language page 
10 as a current hyperlink; scrolling the markup language page in a direction on the screen display in response to a user 
input to display only a portion of the markup language page; determining whether a next hyperlink in the direction of 
scrolling is visible; responsive to the next hyperlink in the direction of scrolling being visible, making next hyperlink the 
current hyperlink; and responsive to the next hyperlink in the direction of scrolling not being visible, scrolling a portion 
of the markup language page. 

IS [0017] According to a second embodiment of the present invention, there is provided a computer implemented meth- 
od of navigating a page of data including at least one selectable hyperlink, In a computer system including a screen 
display but not including an independent cursor controlled by a peripheral pointing device, the method comprising: 
scrolling the page in a direction on the screen display in response to a user input to display only a portion of the page; 
and automatically and iterallvely assigning a next visible hyperlink in the direction of the scrolling and in the displayed 

20 portion of the page to a user selectable key 

[001 8] According to a third embodiment of the present invention, there is provided a computer implemented method 
of navigating a page of data including a plurality of fonn fields, each form field having a type, in a computer system 
including a screen display and a keypad having a plurality of keys, but not including an independent cursor controlled 
by a peripheral pointing device, the method comprising: scrolling the page in a direction on the screen display in re- 

25 sponse to a user input to display only a portion of the data file; determining whether a next form field in the direction 
of scrolling is visible; responsive to the next form field in the direction of scrolling being visible, making the next form 
field a current form field for receiving a user input; and assigning an action for manipulating the current form field to a 
key of the key pad according to the type of the current form field. 

[0019] In one aspect of the present invention, there is provided a wireless communication device comprising: a screen 
30 display; a memory; a processor coupled to the screen display and the memory; a plurality of user interface pages 
stored in the memory and encoded in a markup language, selected ones of the user interface pages providing access 
to telecommunication functions of the wireless communication device; and a markup language browser, executed by 
the processor, and communicatively coupled to the memory and the screen display, that: accesses either the stored 
user interface pages from the memory or remotely stored pages encoded in the markup language via a telecommuni- 
35 cations network; decodes accessed pages to display user interface elements on the screen display; and effects a 
telecommunication function in response to a user input to a displayed user interface element. 

[0020] In another aspect of the present invention, there is provided a wireless communication device, comprising: a 
shell for receiving a URL having a protocol component and a data component: the data specifying a command to be 
executed or content to be fetched, the shell providing the data component to a protocol handler according to the protocol 

40 component, and the fetched content to a content handler for processing; a plurality of protocol handlers, each protocol 
handler coupled to the shell to receive a URL and either fetch content specified by the data component and provide 
the fetched content to the shell, or execute the command specified by the data component; and a plurality of content 
handlers, each content handler couple to the shell to receive fetched content and process the fetched content to output 
the content to a screen display. 

45 [0021] In one embodiment of the wireless communication device, the plurality of protocol handlers Include: a tele- 
phone protocol handler that receives a URL from the shell and decodes the URL to activate a telephony function of 
the wireless communications device; a file protocol handler that receives a URL from the shell and decodes the URL 
to access data stored in a memory of the wireless communications device; a remote file protocol handler that receives 
a URL from the shell and fetches content addressed by the data component of the URL that is stored remotely from 

so the wireless communication device; and the plurality of content handlers include: a markup language content handler 
that receives markup language content corresponding to a URL and displays the content on the screen display. 
[0022] Preferably, the plurality of protocol handlers include: a message protocol handler that receives a URL from 
the shell and executes a command specified by the data to activate an alphanumeric message display or transmission 
function of the communication device; and a configuration protocol handler that receives a URL from the shell and 

55 establishes a configuration setting of the communications device according to the data component of the URL. 

[0023] In another embodiment, the wireless communication device includes a screen display; a memory coupled to 
the screen display, and storing the shell, the protocol handlers, and the content handlers; and a processor coupled to 
the memory to execute the shell, the protocol handlers and content handlers. 
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[0024] In another aspect of the present invention there is provided a computer-implemented method of operating a 
wireless communications device having a plurality of keys, comprising: receiving a first markup language page con- 
taining a tag defining an association between one of the keys and an action; receiving a user selection of the key; and 
effecting the action associated with the user selected key. 
5 [0025] Preferably, the action is a URL having a data component, further comprising: responsive to the data component 
of the URL specifying a second page to be fetched, fetching the second page^ and displaying the second page; and 
responsive to the data component of the URL specifying a telephony command of the wireless communication device, 
executing the telephony command. 

[0026] In another aspect of the present invention, there is provided a browser program product for controlling the 
10 operation of a wireless communication device by execution of the browser by a processor of the wireless communication 

device, the browser executing the operations of: decoding a markup language page including a key tag specifying one 

of the plurality of keys and an action; storing an association between the specified key and the action; and responsive 

to receiving a user input of the specified key, effecting the action associated with the specified key. 

[0027] Preferably, the key tag specifies a URL, and responsive to user input of the specified key, the browser fetches 
IS content associated with the URL and displays the content. 

[0028] Preferably, the key tag specifies a label associated with the specified key, and the browser responsive to 

decoding the page, displays the label on a screen display. 

[0029] In another aspect of the present invention, there is provided a computer implemented method for automatfcally 

displaying help data to a user, comprising: displaying a window having a title in a title bar area; incrementing a counter 
^ of an amount of time elapsed since a last user input; and responsive to the counter equaling or exceeding a threshold 
amount of time, replacing the title by scrolling first help data in the title bar area. 

-[0030] In one embodiment, the method further comprises responsive to a completion of scrolling the first help data: 
redisplaying the title in the title bar; resetting the counter; incrementing the counter of an amount of time elapsed since 
the last user input; and responsive to the counter equaling or exceeding the threshold amount, replacing the title bar 
25 by scrolling second help data in the title bar. 

[0031] In another embodiment, the method further comprises the initial steps of receiving markup language page 
including a title tag defining the title and a help tag defining the first help data; storing the first help data; and displaying 
the markup language page in the window including displaying the title in the title bar 

[0032] , In another aspect of the present invention, there is provided a browser program product for controlling the 
30 operation of a wireless communication device by execution of the browser by a processorof the wireless communication 
device, the browser executing the operations of: decoding a markup language page including title tag defining a title 
of the page and a help tag specifying help data; storing the help data; displaying the page in a window; displaying the 
title in a title bar area of the window; responsive to an elapsed amount of time since a last user input exceeding a 
threshold, replacing the title in the title bar area by scrolling the stored help data in the title bar; and responsive to 
35 completion of the scrolling of the stored help data, redisplaying the title in the title bar area. 

[0033] In another aspect of the present invention, there is provided a computer implemented method of operating a 
wireless communications device having at least one softkey, comprising: receiving a first user interface definition page 
defined in a markup language; parsing the first user interface definition page, and storing an association between one 
of the softkeys and menu of menu Items, each menu item associated with either a URL or an action; responsive to 
*o receiving a user selection of the softkey. displaying the menu of menu items; responsive to user selection of a displayed 
menu item associated with an action, effecting the action; and responsive to user selection of a menu item associated 
with a URL, either fetching data specified by the URL or effecting a communication function of the wireless communi- 
cation device specified by the URL. 

[0034] In another aspect of the present invention, there is provided a browser program product for controlling the 
t5 operation of a wireless communication device by execution of the browser by a processor of the wireless communication 
device, the browser executing the operations of: retrieving a first user interface definition page defined in a markup 
language; parsing the first user interface definition page, and storing an association between one of the softkeys and 
menu of menu Items, each menu item associated with either a URL or an action; responsive to receiving a user selection 
of the softkey, displaying the menu of menu items; responsive to user selection of a displayed menu item associated 
'*o with an action, effecting the action; and responsive to user selection of a menu item associated with a URL, either 
fetching data specified by the URL or effecting a communication function of the wireless communication device specified 
by the URL. 

[0035] In another aspect of the present invention, there is provided a computer implemented method for displaying 
a page of data, comprising: receiving a first markup language page containing a tag specifying a URL referencing a 
5 second markup language page; fetching the second markup language page according to the URL; replacing the tag 
with the second markup language page to form a combined markup language page; and displaying the combined 
markup language page. 

[0036] In another aspect of the present invention, there Is provided a browser program product for controlling the 
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operation of a wireless communication device by execution of the browser by a processor of the wireless communication 
device, the browser executing the operations of: receiving a first markup language page containing a template tag, the 
template tag specifying a URL referencing a second markup language page; fetching the second markup language 
page according to the URL; replacing the template tag with the second markup language page to form a combined 

5 markup language page; and displaying the combined markup language page. 

[0037] In another aspect of the present invention, there is provided a browser program product for controlling the 
operation of a wireless communication device by execution of the browser by a processor of the wireless communication 
device, the browser executing the operations of: receiving a first markup language page containing an escape sequence 
specifying a URL referencing a second markup language page; fetching the second markup language page according 

10 to the URL; replacing the escape sequence with the second markup language page to form a combined markup lan- 
guage page; and displaying the combined markup language page. 

[0038] In another aspect of the present invention, there is provided a computer implemented method of displaying 
a page of configuration settings for a wireless communication device having a plurality of configurable features, the 
method comprising: receiving a markup language page including an input type tag defining an Input field for receiving 

^5 a user input of a configuration setting, and a selection attribute equal to the value of an expression including a URL 
for a configurable feature, the selection attribute indicating whether the input field is preselected; fetching data asso- 
ciated with the URL; evaluating the expression using the fetched data to determine a value of the expression; and 
displaying the page Including the input field of the configuration setting according to the selection attribute as pre- 
selected or unselected according to the value of the expression. 

20 [0039] In one embodiment, the expression has the form (selection attribute=[!]URL); and evaluating the expression 
using the fetched data to determine a value of the expression comprises: converting the data associated with the URL 
to an integer value; and evaluating the expression to obtain either a zero or non-zero value. 

[0040] In another embodiment, the expression has the form (selection attribute = (URL[l]=string)), where string is an 
arbitrary alphanumeric string; and evaluating the expression using the fetched data to determine a value of the ex- 
25 pression comprises: evaluating the expression by determining if the data associated with the URL Is the same as the 
string to obtain either a zero or non-zero value. 

[0041] In another aspect of the present invention, there is provided a browser program product for displaying a page 
of configuration settings for a wireless communfcation device having a plurality of configurable features, the browser 
controlling the operation of a wireless communication device by execution of the browser by a processor of the wireless 

30 communication device, the browser executing the operations of: receiving a markup language page including an input 
type tag defining an input field for receiving a user input of a configuration setting, and a selection attribute equal to 
the value of an expression including a URL, for a configurable feature, the selection attribute indicating whether the 
Input field is preselected; fetching data associated with the URL; evaluating the expression using the fetched data to 
detemilne a value of the expression; and displaying the page including the input field of the configuration setting ac- 

35 cording to the selection attribute as pre-selected or unselected according to the value of the expression. 

[0042] In another aspect of the present invention, there is provided a computer implemented method for displaying 
a page of data, comprising: receiving a markup language page including a conditional tag having an expression In- 
cluding a URL and first markup language data to be conditionally displayed according to the value of the expression; 
fetching data associated with the URL; evaluating the expression using the fetched data to determine a value of the 

40 expression; responsive to the value of the expression being true, displaying the markup language page with the first 
markup language data; and responsive to the value of the expression being false, displaying the markup language 
page without the first markup language data. 

[0043] Preferably, the conditional tag includes second markup language data; and responsive to the value of the 
expression being false, displaying the markup language page without the first markup language comprises displaying 

^5 the markup language page with the second markup language data. 

[0044] In another aspect of the present invention, there is provided a browser program product for controlling the 
operation of a wireless communication device by execution of the browser by a processor of the wireless communk:atlon 
device and displaying a page of markup language data, the browser executing the operations of receiving a markup 
language page including a conditional tag having an expression Including a URL and first markup language data to be 

50 displayed according to the value of the expression; fetching data associated with the URL; evaluating the expression 
using the fetched data to determine a value of the expression; responsive to the value of the expression being true, 
displaying the markup language page with the first markup language data; and responsive to the value of the expression 
being false, displaying the markup language page without the first markup language data. 

[0045] In another aspect of the present invention, there is provided a computer implemented method for navigating 
55 a markup language page containing a plurality of hyperiinks, the method comprising: receiving a markup language 
page including a plurality of hyperiinks; selecting a hyperiink of the markup language page as a current hyperlink; 
scrolling the mari(up language file in a direction on the screen display In response to a user Input to display only a 
portion of the markup language file; detemnining whether a next hyperlink in the direction of scrolling is visible; respon- 
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sive to the next hyperlink In the direction of scrolling being visible, making next hyperlink the current hyperlink; and 
responsive to the next hyperlink in the direction of scrolling not being visible, scrolling a portion of the markup language 
file. 

[0046] Preferably, the nnarkup language page has an attribute specifying a target nanne of a hyperlink included in 
5 the page; and selecting a hyperlink of the markup language page as a current hyperlink further comprises: comparing 
the target name specified in the attribute with names specified in each of the hyperlinks; and selecting as the current 
hyperlink the hyperlink having a name matching the target name. 

[0047] In another aspect of the present invention, there is provided a computer Implemented methodfor automatically 
displaying advertising data to a user, comprising: receiving a markup language page containing a <MARQUEE> tag 
10 including displayable text in a header portion of the page, and a title; displaying the markup language page in a window 
having the title in a title bar area; Incrementing a counter of an elapsed amount of time; and responsive to the counter 
equaling or exceeding a threshold amount of time, replacing the title by scrolling the displayable text included in the 
<MARQUEE> tag in the title bar area. 

[0048] In another aspect of the present invention, there is provide.-d a browser program product for controlling the 
IS operation of a wireless communication device by execution of the browser by a processor of the wireless communication 
device and displaying a page of markup language data, the browser executing the operations of: receiving a markup 
language page containing a <MAROUEE> tag including displayable text in a header portion of the page, and a title; 
displaying the markup language page in a window having the title In a title bar area; incrementing a counter of an 
elapsed amount of time; and responsive to the counter equaling or exceeding a threshold amount of time, replacing 
20 the title by scrolling the displayable text included in the <MARQUEE> tag in the title bar area. 

[0049] In another aspect of the present invention, there is provided a computer-implemented method of operating a 
wireless communications device having a screen display, a plurality of keys, including at least one softkey, and a 
plurality of configurable features that can be established by configuration settings, the method comprising: a) receiving 
a first markup language page including at least one tag selected from a group of tags consisting of: a first tag defining 
?5 an association between a key and an action; a second tag defining help data; a third tag defining an association between 
a softkey and a menu of menu Items; each menu item associated with either a URL or an action; a fourth tag specifying 
a URL referencing a second markup language page; a fifth tag accompany an escape sequence specifying a URL 
referencing a third markup language page; a sixth tag defining an input field for receiving a user input of a configuration 
setting, and a selection attribute equal to the value of an expression including a URL for a configurable feature, the 
30 selection attribute indicating whether the input field is preselected; a seventh tag having an expression Including a URL 
and first mark-up language data to be condlttonally displayed according to the value of the expression; an eighth tag 
having attribute specifying a target name of at least one hyperlink included in the first markup language page; and a 
ninth, <MARQUEE> tag including displayable text in a header portion of the first markup language page; b) responsive 
to a tag in the first markup language being the first tag: receiving a user selection of the key; and effecting the action 
25 associated with the user selected key; c) responsive to a tag in the first markup language page being the second tag: 
storing the help data; displaying the first mark-up language page in a window; displaying a title of the first markup 
language page in a title bar area of the window; responsive to an elapsed amount of time since a last user input 
exceeding a threshold, replacing the title in the title bar area by scrolling the stored help data in the title bar; and 
responsive to completion of the scrolling of the stored help data, redisplaying the title in the title bar area; d) responsive 
fo to a tag in the first markup language page being the third tag: storing the association between the softkey and the 
menu of menu items; responsive to receiving a user selection of the softkey, displaying the menu of menu items; 
responsive to user selection of a displayed menu item associated with an action, effecting the action; and responsive 
to user selection of a menu item associated with a URL, either fetching data specified by the URL or effecting a com- 
munication function of the wireless communication device specified by the URL; e) responsive to a tag In the first 
markup language page being the fourth tag: fetching the second markup language page according to the U RL; replacing 
the fourth tag with the second markup language page to fonn a combined markup language page; and displaying the 
combined markup language page; f) responsive to a tag in the first markup language page being the fifth tag: fetching 
the third markup language page according to the URL; replacing the escape sequence with the third markup language 
page to form a combined markup language page; and displaying the combined markup language page; g) responsive 
'0 to a tag in the first markup language page being the sixth tag: fetching data associated with the URL; evaluating the 
expression using the fetched data to determine a value of the expression; and displaying the first markup language 
page including the input field of the configuration setting according to the selection attribute as pre-selected or unse- 
lected according to the value of the expression; 

h) responsive to a tag in the first markup language page being the seventh tag: fetching data associated with the URL; 
•5 evaluating the expression using the fetched data to determine a value of the expression; responsive to the value of 
the expression being true, displaying the first markup language page with the first markup language data; and respon- 
sive to the value of the expression being false, displaying the first markup language page without the first markup 
language data; i) responsive to a tag in the first markup language page being the eighth tag: selecting one of the 
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hyperlinks of the first markup language page as a current hyperlink; scrolling the first markup language page in a 
direction on the screen display in response to a user input to display only a portion of the first markup language page; 
determining whether a next hyperlink in the direction of scrolling is visible; responsive to the next hyperlink In the 
direction of scrolling being visible, making next hyperlink the current hyperlink; and responsive to the next hyperlink in 
5 the direction of scrolling not being visible, scrolling a portion of the first markup language page; and j) responsive to a 
tag in the first markup language page being the ninth tag: displaying the first markup language page in a window having 
a title of the first markup language page in a title bar area; incrementing a counter of an elapsed amount of time; and 
responsive to the counter equaling or exceeding a threshold amount of time, replacing the title by scrolling the display- 
able text included In the <MARQUEE> tag in the title bar area. 
10 [0050] In another aspect of the present invention, there is provided a browser program product for controlling the 
operation of a wireless communication device by execution of the browser by a processor of the wireless commun ication 
device having a screen display, a plurality of keys, including at least one softkey, and a plurality of configurable features 
that can be established by configuration settings, the browser executing the operations of: a) receiving a first markup 
language page including at least one tag selected from a group of tags consisting of: a first tag defining an association 
IS between a key and an action; a second tag defining help data; a third tag defining an association between a softkey 
and a menu of menu items, each menu item associated with either a URL or an action; a fourth tag specifying a URL 
referencing a second markup language page; a fifth tag accompany an escape sequence specifying a URL referencing 
a third markup language page; a sixth tag defining an input field for receiving a user input of a configuration setting, 
and a selection attribute equal to the value of an expression including a URL for a configurable feature, the selection 
20 attribute indicating whether the input field is preselected; a seventh tag having an expression including a URL and first 
markup language data to be conditionally displayed according to the value of the expression; an eighth tag having 
attribute specifying a target name of at least one hyperlink included in the first markup language page; and a ninth, 
<MARQUEE> tag including displayable text in a header portion of the first markup language page; b) responsive to a 
tag in the first markup language page being the first tag: receiving a user selection of the key; and effecting the action 
25 associated with the user selected key; c) responsive to a tag in the first markup language page being the second tag: 
storing the help data; displaying the first markup language page in a window; displaying a title of the first markup 
language page in a title bar area of the window; responsive to an elapsed amount of time since a last user input 
exceeding a threshold, replacing the title in the title bar area by scrolling the stored help data in the title bar; and 
responsive to completion of the scrolling of the stored help data, redisplaying the title in the title bar area; d) responsive 
30 to a tag in the first markup language page being the third tag: storing the association between the softkey and the 
menu of menu items; responsive to receiving a user selection of the softkey displaying the menu of menu items; 
responsive to user selection of a displayed menu item associated with an action, effecting the action; and responsive 
to user selection of a menu item associated with a URL, either fetching data specified by the URL or effecting a com- 
munication function of the wireless communication device specified by the URL; e) responsive to a tag in the first 
35 markup language page being the fourth tag: fetching the second markup language page according to the URL; replacing 
the fourth tag with the second markup language page to form a combined markup language page; and displaying the 
combined markup language page; f) responsive to a tag in the first markup language page being the fifth tag: fetching 
the third markup language page according to the URL; replacing the escape sequence with the third markup language 
page to form a combined markup language page; and displaying the combined markup language page; g) responsive 
40 to a tag in the first markup language page being the sixth tag: fetching data associated with the URL; evaluating the 
expression using the fetched data to determine a value of the expression; and displaying the first markup language 
page including the input field of the configuration setting according to the selection attribute as pre-selected or unse- 
lected according to the value of the expression; h) responsive to a tag in the first markup language page being the 
seventh tag: fetching data associated with the URL; evaluating the expression using the fetched data to determine a 
45 value of the expression; responsive to the value of the expression being true, displaying the first markup language 
page with the first markup language data; and responsive to the value of the expression being false, displaying the 
first markup language page without the first markup language data; i) responsive to a tag in the first markup language 
page being the eighth tag: selecting one of the hyperlinks of the first markup language page as a current hyperlink; 
scrolling the first markup language page in a direction on the screen display in response to a user input to display only 
so a portion of the first markup language page; determining whether a next hyperlink in the direction of scrolling is visible; 
responsive to the next hyperlink in the direction of scrolling being visible, making next hyperlink the current hyperlink; 
and responsive to the next hyperlink in the direction of scrolling not being visible, scrolling a portion of the first markup 
language page; and j) responsive to a tag in the first markup language page being the ninth tag: displaying the first 
markup language page in a window having a title of the first markup language page in a title bar area; incrementing a 
55 counter of an elapsed amount of time; and responsive to the counter equaling or exceeding a threshold amount of 
time, replacing the title by scrolling the displayable text included in the <MARQUEE> tag in the title bar area. 
[0051 ] In another aspect of the present invention, there is provided a method of configuring a wireless communication 
device having a display screen and a plurality of user selectable keys, the method comprising: receiving a data file 
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including content and markup language tags defining an arrangement of the content on the display screen, a portion 
of the content associated with a URL; responsive to the markup language tags, displaying the portion of the content 
associated with the URL on the display screen in a visually distinguished manner; responsive to the markup language 
tags, assigning the URL associated with the visually distinguished content to one of the userselectable keys; receiving 
5 a user selection of the assigned user selected key; and accessing a data file or function associated with the URL 
assigned to the user selected key. 

[0052] In another aspect of the present invention, there is provided a computer implemented method of processing 
data in a form In a stateless system having a server and a client device receiving input data, the method comprising: 
receiving on the client device a first markup language page including a first part of a form having at least one input 
10 field for receiving user input of data; receiving a first user input of first data into the first part of the form on the client 
device; receiving a second markup language page on the client device including a second part of the form while storing 
locally on the client the received first data; receiving a second user input of second data into the second part of the 
form on the client device; combining the stored first data and the second data into a URL; and submitting the URL to 
the server for processing. 

15 [0053] In another aspect of the present invention, there is provided a wireless communication device, comprising: a 
screen display; a plurality of keys; a plurality of configurable features; a processor coupled to the screen display and 
the keys; a shell executed by the processor for receiving a URL having a protocol component and a data component, 
the data specifying a command to be executed or content to be fetched, the shell providing the data component to a 
protocol handler according to the protocol component, and the fetched content to a content handler for processing; a 

20 plurality of protocol handlers, each protocol handler executed by the processor and coupled to receive a URL from the 
shell and either fetch content specified by the data component and provide the fetched content to the shell, or execute 
the command specified by the data component; and a markup language content handler executed by the processor 
and coupled to the shell that receives markup language content corresponding to a URL and displays the content on 
the screen display, the markup language handler decoding markup language tags from a group comprising: a key tag 

25 defining an action for one of the plurality of keys; a help tag defining help text data to be periodically displayed on the 
screen display; a keymenu tag defining a menu item for a menu associated with a key; a tag specifying a second 
markup language page different from a first markup language page for including the data of the second markup Ian- 
guage page in the first markup language page; an input type tag defining an input field for receiving a user input of a 
configuration setting, and a selection attribute equal to the value of an expression including a URL for a configurable 

30 feature, the selection attribute indicating whether the input field is preselected; and a conditional tag having an expres- 
sion including a URL and first markup language data to be conditionally displayed according to the value of the ex- 
pression. 

[0054] In another aspect of the present Invention, there is provided a wireless communication device comprising: a 
screen display; a memory; a processor coupled to the screen display and the memory; a plurality of user interface 

35 pages stored in the memory and encoded in a markup language, selected ones of the user interface pages providing 
access to telecommunication functions of the wireless communication device; and browser means executed by the 
processor, and communicatively coupled to the memory and the screen display, and including: means for accessing 
either the stored user Interface pages from the memory or remotely stored pages encoded in the markup language via 
a telecommunications network; means for decoding accessed pages to display user interface elements on the screen 

to display; and means for effecting a telecommunication function in response to a user input to a displayed user interface 
element. 

[0055] In another aspect of the present invention, there is provided an apparatus, comprising: first means for receiving 
a URL having a protocol component and a data component, the data specifying a command to be executed or content 
to be fetched, the shell providing the data component to a protocol handler according to the protocol component, and 

'5 the fetched content to a content handler for processing; a plurality of protocol handler means, each protocol handler 
means coupled to the first receiving means to receive a URL and either fetch content specified by the data component 
and provide the fetched content to the shell, or execute the command specified by the data component; and a plurality 
of content handler means, each content handler means coupled to the first means to receive fetched content and 
process the fetched content to output the content to a screen display. 

'0 [0056] In another aspect of the present invention, there is provided a computer implemented method of data process- 
ing a page of data encoded In a markup language, the page including a reference to an embedded object, the method 
comprising: receiving a user selection of a displayed user interface element in the page, the element associated with 
a URL encoded within the page, the URL having a protocol component and a data component; invoking the embedded 
object, and providing the URL to the embedded object for processing; and responsive to the embedded object not 

5 processing the URL, fetching content specified by the data component, or executing a command specified by the data 
component. 

[0057] In another aspect of the present invention, there is provided a computer implemented method of data process- 
ing a page of data encoded in a markup language, the method comprising: receiving a user selection of a displayed 
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user interface element in the page, the element associated with a command encoded within the page, the command 
having a protocol component and a data component; and invoking the embedded object, and providing the command 
to the embedded object for processing, the embedded object processing the command using an internally defined 
function. 

5 [0058] The present invention overcomes the various limitations of conventional wireless communication devices by 
providing a wireless communication device with an MM I that is based on a markup language. A markup language is 
a computer programming language that allows the content of a page or a screen display to be defined by the inclusion 
of predefined symbols in the content itself indicating the logical components of the content, instructions for the layout 
of the content on the page or screen, or other data which can be interpreted by some automatic system responsible 
10 for displaying, manipulating or modifying the content. 

[0059] In one aspect the present invention provides a wireless communication device including a user interface 
defined in a markup language. To effect this, the present invention includes a markup language browser that it uses 
to provide both telephony control of the wireless communication dfivice, in response to user selection of telephony 
functions in the user interface and Internet access via the HyperTe <t Transport Protocol (HTTP), in response to user 
15 selection of data items associated with content located on the Internet. 

[0060] In one embodiment, the telecommunication control and other functions of the wireless communication device 
are defined in various user interface pages written In a markup language. Each control function is associated with, or 
activated by a Uniform Resource Locator (URL). A URL is a data item specifying a protocol for obtaining a data item, 
and which data item should be fetched or manipulated. The user interface pages are stored in a local memory of the 
20 wireless communication device, and fetched by the browser, which decodes them and displays the appropriate user 
interface elements. The browser can also modelessly fetch markup language pages or other content that is stored 
remotely, by accessing such pages via a telecommunications network such as the World Wide Web, and likewise 
decode and display these remotely accessed pages. When a user interface page is displayed, user selection of a 
control function passes a URL or command data to the browser. The browser effects a telecommunication function in 
2S response the received URL or command. 

[0061] The browser preferably includes a number of protocol handlers, Including a telephony protocol handler, a 
local file protocol handler, and an remote file protocol handler, and a number of content handlers, including a markup 
language handler. The telephony protocol handler decodes URLs for telephony control features, such as telephone 
dialing and answering, activates underlying functions of telephony control software controlling the hardware of the 
30 wireless communication device. Any content of the URL which is needed to display the telephony controls Is provided 
to the markup language content handier which parses the content and displays it on a screen display. The markup - 
language content handler is generally responsible for displaying any fetched markup language pages, including all 
user interface pages, and for receiving user inputs to these pages via fonns and other input means. 
[0062] The markup language handler generally receives content from two sources, the local file protocol handler and 
55 the remote file protocol handler. The remote file protocol handler decodes URLs for accessing content on the World 
Wide Web, and provides the fetched content, such as a Web page, form, applet, or the like to the markup language 
content handler for outputting the content to the screen display of the wireless communication device. One suitable 
remote file protocol handler Implements HTTP. The local file protocol handler decodes URLs for accessing local user 
interface files and provides such content to the markup language content handler. In a preferred embodiment of the 
40 MMI, the user interface is defined in HyperText Markup Language, or "HTML," and the browser includes a HTML, 
content handler that displays both Web content and user interface featured defined in HTML. 

[0063] The use of a markup language to define the MMI of a wireless communication device provides numerous 
advantages over conventional MMI software architectures. First, the use of a markup language allows for complete 
and seamless integration of Internet and World Wide Web access into the telephony and other features of the wireless 

45 communication device. Since the MMI uses a markup language such as HTML to display all the functional screens, 
the Worid Wide Web content (which is also wriuen in HTML) has the same appearance as otherfeatures of the wireless 
communication device. More particularly, the pages of the MMI are accessed using URLs, just as Web content is 
similarly accessed. When displaying a functional page the wireless communication device accesses a local URL; when 
displaying Web content, the wireless communication device automatically initiates a connection with a Web server to 

50 obtain the Web content. The markup language based MMI thus allows for a modeless user interface that enables the 
user to access the Internet and the World Wide Web at any time, without having to switch the wireless communication 
device between telephony and "browser" modes, as in conventional devices. 

[0064] As a further benefit of the markup language based MMI. Web content such as Web pages, forms, and the 
like, from the World Wide Web can be accessed and incorporated directly into telephony, messaging, and other non- 
55 Internet based features of the wireless communication device. For example, in a preferred embodiment, a wireless 
communication device has a telephone book of stored telephone numbers and names. Conventionally, the user would 
have to manually key these entries In using the keypad of the wireless communication device. In a wireless commu- 
nication device using an MMI in accordance wrth the present invention, the user could add an entry to the telephone 
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book simply by accessing a telephone directory on the World Wide Web, which can contain HTML that allows the user 
to easily store the information directly into the telephone book. 

[0065] The use of a markup language also reduces the complexity of the software engineering process for creating 
the MMI for a particular wireless communication device. First, since the MM I of the present invention is based on a 
5 markup language, only a very limited amount of programming skill is needed to design a fully featured user interface, 
unlike a conventional MMI which requires a programmer skilled in C or other low level language programming. Editing 
and modifying the user interface requires only simple markup language and image editing tools, not a complete appli- 
cation programming environment. Second, using the markup language based MMI of the present invention enables 
any of the features the MMI to be modified, without having to re-compile the entire telephone control software, and re- 

^0 test and certify the entire package. Because the MMI is separate from the underlying telephone control and air interface 
stack, only user interface pages that are individually changed or added need to be tested. This reduces the time to 
market, and increases the ease of designing, maintaining, and modifying the MMI as new features and services become 
available. Reduction of the time to create and test changes in the user interfaces also means that more different versions 
can be prototyped In less time than with a conventional MMI, thereby facilitating design exploration for the best user 

^5 interface design for a given set of user requirements and features. 

[0066] The ease with which the user interface of a MMI can be created and modified, and the reduction of time to 
market further enables the service operator to quickly generate wireless communication devices targeted at specific 
customer segments, without requiring the device manufacturer to create specific product software images for each 
and every target customer segment. For example, the service operator may use the same wireless communication 

2o device hardware and telephony control software with different user interfaces designed for executives, teen-agers and 
seniors, each of which may have different needs, and abilities to use the features of the wireless communication device. 
[0067] For example, using a markup language to define the pages of the user interface allows any of the following 
items to be changed on any page: title bar presence and text; all informational text; option list text; links to all subsequent 
screens; soft key assignments; permanent scrolling banner messages; banner advertising; and help text. 

25 [0068] The use of markup language based MMI also provides advantages in the branding of the wireless communi- 
cation device for different service operators. Since the user interface is defined in markup language pages, service 
operator-specific logos, artwork, and text can be easily added and changed by individual service operators. Thus, the 
wireless communication device can provide the same wireless communication device hardware and telephone control 
software to a number of service operators, each of whom can quickly and easily brand the wireless communication 

30 device with their own distinctive user interfaces, without requiring the wireless communication device manufacturer to 
implement, test, and ship different user interfaces to each operator as is conventional. 

[0069] In providing a wireless communication device with a markup language based MMI, the present invention 
enhances the standard HTML with a number of extensions that make it particularly useful for working with wireless 
communication devices. Standard HTML assumes the presence of a conventional computer with keyboard, pointing 
35 device, and full size display screen, features which are not present in most wireless communication devices. The most 
notable deficiencies of HTML include: 



• Form elements (e.g., checkboxes, radio buttons) are awkward to navigate without a mouse. 

• Forms as they exist in content today tend to be too large for the user to maintain some context as she is filling 
them in on a small screen. If the form is divided into n forms, then the user's Input is sent between the client and 
the server and back to the client n-1 times, wasting bandwidth. In addition, with aseries of smaller forms .terminating 
the transaction could be tortuous as the user hits the back key for each fomn in the series. 

• Hyperlinks are awkward to follow without a mouse to select them and a separate scrollbar for scrolling the content 
of a page. On a device with only an Up key and a Down key to both select which hyperlink to follow and to scroll 
the display, fixed assignment of either scrolling or selecting to the Up and Down keys Is Insufficient to provide the 
needed navigational abilities. 

As a user interface definition language, HTML lacks a number of key features: 

• The ability to specify actions for the soft function keys, or indeed for any key on the device. 

• The ability to define a pop-up menu of choices. 

• The ability to display or alter the data you'd like to store on the device, such as names and phone numbers. 

• The ability to design a screen as a template without writing C code to fill in the blanks. 

• The ability to allow content arriving over the airto extend or customize the Interface the device presents to the user. 

[0070] The present invention provides extensions to the HTML language which facilitate the design of multi-part 
forms, the use of a limited number of keys to both navigate Web pages and select hypertext links, define actions for 
any key (keypad or softkey) of the wireless communication device using URLs, create menus of options for softkeys, 
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and conditional inclusion of text, formatting, and user interface gadgets. 

[0071] More particularly, the present invention provides a "key" tag that allows the assignment of specific functions 
or actions to any key of a key-pad, including binding a menu to a key. A "keymenu" tag allows specification of the menu 
items to be included In a menu bound to a key. A "template" tag and an "include" tag allow for the substitution or 

5 insertion of external HTML or other data directly into the HTML of a page. A "help" tag allows for the definition of help 
strings that are automatically scrolled across the title bar of page after a set time period. A conditional tag allows for 
the testing of expressions to conditionally display HTML data within a page, for example based on variables or config- 
uration settings of the device. A "next" method for forms allows for maintaining state of a multi-part fomn without having 
to repeatedly transmit hidden data between a client and server to maintain the state. Improved navigational methods 

10 allow for the Up and Down keys of a wireless communication device to control both scrolling of a page, and selection 
of user interface gadgets and hyperlinks, in the absence of separate Tab and Enter keys and scroll bars. 

BRIEF DESCRIPTION OF THE DRAWINGS 



15 [0072] Fig. 1 is an illustration of the top level software and system architecture of a wireless communication device 
in accordance with the present invention. 

[0073] Fig. 2 is an illustration of a sample user Interface page for a wireless communrcation device is accordance 
with the present Invention. 

[0074] Fig. 3 is an illustration of the detailed software architecture of a man-machine interface of a wireless commu- 

^0 nication device in accordance with the present Invention. 
[0075] Fig. 4 is an illustration of the URL history stack. 

[0076] Fig. 5 is a flowchart of the operation of the shell in handling received URLs. 

[0077] Fig. 6 is a flowchart of the operation of the HTMLp content handler in processing a string input associated 
with a user interface gadget 

25 [0078] Fig. 7 is an example HTMLp file and page showing a key menu using the <KEY> and <KEYMENU> tags. 

[0079] Fig. 8 is an example HTMLp file and page showing a help text scrolling banner with the <HELP> tag. 

[0080] Fig. 9 is an example HTMLp file and page showing the use of the <TEMPLATE> tag for template files. 

[0081] Fig. 10 is an example HTMLp file and page for editing a phone book. 

[0082] Fig. 11 is another example HTMLp file and page for editing a phone book. 
30 [0083] Fig. 12 is an example HTMLp file and page showing the use of expressions for evaluating the CHECKED and 

SELECTED attributes. 

[0084] Fig. 13 is an example HTMLp file and page showing included HTML with the <INC> tag. 

[0085] Fig. 14 is an example HTMLp file and page using the PHONENUM and PHONENAME attributes for the 

<INPUT> tag. 

35 [0086] Fig. 15 is a flowchart of the process for handling an input key by the HTMLp content handler. 
[0087] Fig. 1 6 is an example conventional HTML file and page for a complex form. 

[0088] Figs. 17a-17b are example HTML files and pages showing an conventional multiple form approach using 
HIDDEN input data. 

[0089] Figs. 1 8a-1 8b are example HTMLp files and pages showing a multi-part fonn used with the NEXT method. 
40 [0090] Fig. 19 is an example HTMLp file and page showing the default creation of a menu of hyperlinks without the 
use of the <LINKMENU> tag. 

[0091] Fig. 20 is an example HTMLp file and page showing the use of the <LINKMENU> tag. 
[0092] Figs. 21a-21e illustrate various user interface pages for dialing a telephone number. 
[0093] Figs. 22a-22c illustrate various user Interface pages for handling active calls. 
45 [0094] Fig. 23 is an example HTMLp file and page showing the use of the "extra" protocol. 
[0095] Fig. 24 Is a table of icons and images used with the buittin protocol. 
[0096] Fig. 25 is an example HTMLp file and page showing the use of the <DtAL> tag. 



so 



DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

A. SYSTEM AND SOFTWARE ARCHITECTURE 



[0097] Referring now to Fig. 1 . there is shown an illustration of the system and software architecture of a wireless 
communication device 100 using the markup language based MM1 102 in accordance with the present invention. The 
55 hardware of the wireless communication device 100 includes a processor 124, memory 126, screen display 136, and 
keypad 128. Memory 126 includes ROM, RAM, and a flash memory for long term storage of data. A suitable wireless 
communication device 100 for providing the hardware features is a Nokia 61 00''^^ manufactured by Nokia Telecommu- 
nications, Inc. 
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[0098] The wireless communication device 100 stores in the memory 126 and executes a conventional real time 
operating system 122, which includes modules for managing power, memory, threads (communication connections), 
keypad inputs, and timer activities. The real time operating system 122 provides a standard application programming 
interface to allow higher level components of the MMI1D2to request functionality of the wireless communication device 

5 100, and to send and receive data. 

[0099] Also stored in the memory 126 and in communication with the real time operating system 122 is telephony 
control module 1 20 that provides the primary telephone controls, including making and receiving telephone calls, man- 
aging multiple telephone lines (if appropriate), management of text messaging (if appropriate), monitoring of telephone 
signals, and other basic telephony functions. The telephony control module 120 includes a conventional telephone 

^0 protocol stack that implements an air-interface protocol. The telephony control module 120 provides an application 
programming interface to the MMI 102 to access these features. The telephony control module 120 and the real time 
operating system 122 are typically provided by the manufacturer of the wireless communication device 100, and their 
particular implementation is not material to the Invention. 

[0100] The screen display 136 is a bitmapped LCD or similar display device. The screen display 136 is typically of 
*5 very limited resolution, for example about 90x60 to 1 20x1 20 pixels (at about .28mm dot pitch) as would be appropriate 
for a compact, portable, hand-held electronic device. It is anticipated that advances In display technology will result in 
screen displays 136 of significantly higher resolution, but even so, the ergonomic and form factor requirements of 
wireless communication devices will result In screen displays that are relatively small (e.g., between 25x25mm and 
80x1 20mm) as compared to the screen displays of notebook and desktop computers, and as a result will not display 
^0 content designed for such larger screen displays in the exactly the same manner. The present invention is adapted to 
Increase the ease of use of such screen displays when displaying Web content. 

[0101] The wireless communication device 100 has a keypad 128 that includes a number of fixed function keys 132 
for accessing defined functions of the wireless communication device 100 (e.g., "Send," "End," and "Power"), number 
keys 134 for entering digits (and If suitably encoded, for entering other characters), and programmable softkeys 130 
^5 which have variable functionality that changes depending on the particular screen display of the user interface 104 
being shown. 

[0102] The wireless communication device 100 stores in its memory 126 and executes an Instance of an MM1 102 
made in accordance with the present Invention. This MMI 102 includes a set of user Interface definition files 104, a 
browser 107, a set of portable components 116, and a portability layer 118. The browser 107 provides the primary 

30 user interface mechanism to the user, allowing access to both telecommunication functions, and Internet/World Wide 
Web access. The portable components 116 provide a set of graphics primitives, file store functions, and localization 
features that allow the browser to be used on a variety of wireless communication devices 100. The portability^ layer 
118 provides an interface for the browser 107 and portable components 116 to the real time operating system 122 and 
the telephone control module 120. 

35 [0103] The MMI 102 executes as a single-threaded application, and is generally designed to run on any real time 
operating system 122, telephone control module 120, and wireless communication device 100 that provides sufficient 
ROM, RAM, and flash memory, a screen display 136, and basic services. 



[0104] The browser 107 provides the basic user interface of the wireless communication device 100 and is respon- 
sible for displaying content on the screen display 136, as defined by the user interface definition files 104, and as may 
be retrieved from remote sites, such as Web content accessed via a communication link to a remote Web site. The 
user interface definition files 104 are a set of content and code files written in a markup language such as HTML, or 
'5 the preferred variant described below, HTMLp, and may include executable embedded code objects. The present 
invention is not limited to HTML, but also operates with, and may extend any other markup language, such as SGML, 
or XML, or other extended non-standard versions of HTML, such as the Netscape Communications' set of HTML 
extensions. 

[0105] Since each service operator providing a wireless communication device using the MMI 102 of the present 
'*o invention will design their own specific user interface, typically modifying some portion of the user interface definition 
files 104 provided by the device manufacturer, the particular content of the user Interface definition files 104 is variable, 
and expected to be different from any of the illustrative user interface screens described herein. In addition, it is expected 
that the MMI 102 may be provided to a service operator without any user interface definition files 104 at all, leaving 
the service operator to create these files as desired; thus the user interface definition files 104, while used by the MMI 
5 102 of the present invention, themselves are not an essential parf of the invention. As the user interface definition files 
104 define the user Interface presented to the user, they allow the service operator to easily and quickly 'brand* the 
wireless communication device 100, by simple editing of the user interface definition files 104. This branding requires 
no recompilation of the underlying browser 107, portability layer 118, or portable components 116, and thereby makes 
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customization very easy and cost effective. It also means that the service operator can customize and brand the user 
interface using simple markup language editing tools, without necessitating the programming skill and environment of 
conventional code development. 

[0106] Following the temiinology of the World Wide Web, an Individual user interface screen is herein called a 
5 "page." Referring now to Fig. 2, there is shown a basic layout of a page 135 displayed on the screen display 136 by 
the browser 107. Each page 135 generally has four basic areas. A status bar 200 that is preferably always present 
and displays items such as signal strength 202 and battery strength 204, message-waiting indicator 206. A title bar 
210 displays the name for a particular screen, if so defined. A status message area 212 may be used to present status 
messages particular to the current content, such as a telephone number being called or answered. A content area 
10 214 is used to display the particular content of a user interface page, for example, text of a message, phone book 
entries, and the like. Along the bottom (though other locations may be used) are softkey labels 216, which are dy- 
namically updated according to key definitions provided in the user interface definition files 104. A scroll arrow 215 
indicates the current direction in which the user is scrolling (either up or down). In the content area 214, a focus and 
selection icon 220 may optionally be used to indicate the particular item or fine of content that has the focus, i.e. is 
IS the current user interface gadget or input field. A mode indicator 218 indicates the mode for text entry, whether alpha, 
numeric, or a combined alphanumeric mode. 

[01 07] Any of the pages or content displayed on the screen display 1 36 may be obtained locally from the user interface 
definition files 104 or remotely from the Internet or World Wide Web. Examples of local content include a telephone 
book, received text messages, or messages being created for sending, configuration settings for the wireless commu- 

^ nication device, and the like. One of the features of the present invention is that whether the content is locally or remotely 
fetched is largely hidden from the user, except for the delay (if any) in obtaining it. This feature enhances the presentation 
of seamlessly integrated Internet and World Wide Web access with telecommunication functions. 
[0108] Most of the features of the user interface are activated by means of a URL (Universal Resource Locator). 
Nominally, a URL is a means of identifying a piece of data, which data may be predefined, or may be generated on 

^5 demand based on arguments that are encoded in the URL. A URL is a string that takes the following form: 
protocol :data'identifiet{'> arguments] 
[0109] The protocol component specifies a communication protocol that should be used to retrieve the data. For 
content located on the World Wide Web, the protocol is usually "http" forthe HyperText Transport Protocol; local content 
of the user interface definition files 104 is retrieved with the "file" protocol to obtain data in a local file system stored in 

30 the memory 126. The present invention provides a number of additional new protocols that control the operation and 
configuration of the wireless communication device 100. 

[0110] The flfiafa-Zdenf/T/er component is a specification of the desired content to be fetched. Currently, for content 
on the Worid Wide Web, the data-identifier normally takes the form of two 7 characters, followed by a machine name, 
another T character, and a path of some sort. 
55 [0111] The arguments, if present, are separated from the data-identifier a '?' and take the form of pairs made of 
an argument name and its value. An character separates an argument name from its value. Multiple arguments are 
separated by an '&* character between the value of one and the name of the next. 

[0112] Architecturally, the browser 107 includes three major pieces: shell 106, protocol handlers 112, and content 
handlers 114. Fig. 3 Illustrates the detailed software architecture of the MM1 102, including browser 107. 
^0 [0113] The shell 106 is responsiblefor maintaining the universal parts of the screen display 136, for processing URLs 
by passing portions of a URL to the correct protocol 112 and content handler 114 forthe URL, for maintaining a history 
stack 108 of URLs, and for routing user input. User input routing involves passing user input keystrokes to the appro- 
priate content handler 114 or other target entity for processing, such as entering input numbers and letters into a form, 
or dialing a telephone number. 

45 [0114] Protocol handlers 112 receive a URL from the shell 106, and are responsible for fetching the data correspond- 
ing to the URL, and instructing the shell 106 which content handler 114 should receive the data. In some cases, the 
URL is a command to control features of the wireless communication devkre 100, which the protocol handler 112 is 
responsible for executing. 

[0115] Content handlers 114 are responsible for displaying fetched URL data and interacting with the user. At least 
so one content handler 114 is always the current content handler 114. It is from the current content handler that any new 
URL is provided back to the shell 106, and that receives by default any keystrokes that are not delivered to any other 
input target. The shell 106 is further described below with respect to Figs. 4-5. 

1 . Overview of the Protocol Handlers 

55 

[0116] The protocol handlers 112 serve two functions in the MM1 102: First, they fetch data and determine its type; 
the determination of type in tum determines whk:h content handler is used to display the data. Second, they perform 
a command in the wireless communication device 100, by accessing an embedded object or the appropriate API of 
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the real time operating system 122, or telephone control module 120. A protocol handler 112 may return the results of 
that command, causing a different screen to display, or may return no results. The protocol handlers 112 of a preferred 
embodiment Include the following. 

[0117] Builtin protocol handler 112a provides access to icons that are built in to the wireless communication device 
5 100. 

[0118] Config protocol handler 112b gets and sets configuration settings of the wireless communication device 100. 
[01 1 9] Extra protocol handler 11 2c provides access to arguments and form data that are passed from an embedded 
object in a page, or from previously accessed pages. This protocol allows data to be passed directly into a page, without 
requiring the page to be dynamically generated. 
10 [0120] File protocol handler 112d provides access to local content in ROM and in the flash file systems. Generally, 
this content is user Interface definition files 104 that define the pages of the user interface. The file protocol handler 
112d may be implemented by those of skill in the art according to a suitable specification for file system access, such 
as the POSIX specification. 

[0121] HTTP hander 112e is a remote file protocol handler that provides accesses to remote content stored on the 
»5 World-Wide Web, using the standard HyperText Transfer Protocol. The HTTP handler 112e may be Implemented by 

those of skill in the art according to the specification defined in RFC 2068; Hypertext Transport Protocol - HTTP/1.1 . 

Other remote file access specifications may also be used to implement a remote file protocol handler. 

[01 22] Message protocol handler 1 1 2f activates various messaging functions, including sending a message, deleting 

a stored message, reading new or stored messages, or locking a stored message. 
20 [0123] Telephone protocol handler 112g activates various telephone functions, including making a call, answering 

an incoming call, displaying the phone book, editing a phone book entry, and creating a new phone book entry. 

[0124] Config protocol handler 112b (shown as part of the portability layer 118) retrieves and sets various configu- 
ration settings for the wireless communication device 100. 



25 a) Basic Protocol Handler API 

[0125] Generally, a protocol handler 112 is similar to a device driver, in that it has a well-defined set of functions it 
can perform, and each protocol handler 112, though supporting the same functions, supports those functions In its 
own manner. Each protocol handler 112 implements three functions; 
30 [0126] GetURL; Given a URL and a security level of the page containing the URL to be fetched, returns the data 
associated with the URL, and the privilege level of that data. If the URL is actually a command, rather than a reference 
to data, no data need be retumed. 

[0127] BuiidURL; Given a full URL and a partial URL (without the protocol: element), returns a full URL. This is used 
primarily for references inside HTML pages. 
?5 [0128] PutURL: Given a URL, a stream of data to be stored under the URL. and the security level of the page con- 
taining a "put" method, stores the data if the security level is high enough to allow it. 

[0129] The various embedded object and command URLs supported by the protocol handlers 112 are described 
below. 



^0 2. Overview of the Content Handlers 



[0130] Content handlers 114 are responsible for decoding the content data of a page corresponding to a fetched 
U RL and displaying the content, or otherwise manipulating the content. A content handler 114 typically decodes content 
It receives and presents a page in the screen display 1 36, or portion thereof. Some content handlers 114 construct the 
'5 page from data they receive from the memory 126 or over a communications link, while others display the state of the 
wireless communication device 100 or serve some other administrative function. In a preferred embodiment of the 
browser 107, the content handlers 114 include the following: 

[0131] CallManager content handler 114b manages an incoming call screen defined in the user interface definition 
files 104 to enable the user to receive incoming calls. The CallManager content handler 114b provides other function- 

•0 ality through eriri bedded objects. 

[0132] HTMLp content handler 1 1 4c displays the bulk of the user interface by accessing the appropriate user interface 
definition files 104 in memory 126. The HTMLp content handler 114c includes a HTML 3.2 compatible parser, and is 
capable of decoding HTML and creating the necessary data structures and objects to display text and graphics ac- 
cording to HTML tags. In addition, the HTMLp content handler 114c accepts a modified form of HTML 3.2, herein called 

5 "HTMLp" as described below, which provides a number of beneficial extensions to the features and functionality of 
HTML 3.2. 

[0133] To better serve as a user interface, and provide added flexibility in designing the user interface, the HTMLp 
content handler 114c allows objects, written in C or other programming language, to be embedded in an HTML or 
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HTMLp page to display different types of data that are in the wireless communication device 100. However, the HTMLp 
content handler 114c, unlike a standard HTML parser, first passes user selected URLs in a current page to any em- 
bedded object, allowing the URL to be modified by what the user has selected or entered or fully processed before 
they are given to the shell 106 to process. 
5 [0134] In the preferred embodiment, the available embedded objects include the following: 

[0135] A phone book object stores records of names, associated telephone numbers, addresses, email addresses, 
speed dial key selection, ring tone, and other definable fields of data. The phone book object includes methods to get 
and set the fields of records. A phone book object may be embedded in a page and activated by the appropriate URL 
of the phone protocol. 

10 [0136] A recent and missed phone call list object stores a continually updated list of telephone numbers that were 
recently called, received, or not answered. The call list object includes methods to delete and dial a telephone number 
on the list. The call list may be embedded in a page and activated by the appropriate URL of the phone protocol. 
[0137] A speed dial number list object stores a set of telephone numbers and associations to keys of the keypad 
128, such that the selection of the key provides for speed dialing functionality. This list object include methods to set, 

IS get, and dial a speed dial number. 

[0138] A phone number lookup object accesses the phone book object to return a telephone number(s) associated 
with an input or selected name or name fragment. 

[0139] A phone book name lookup object accesses the phone book object to return a name(s) associated with an 
input or selected telephone number of number fragment. 
^ [01 40] A list object of text messages/alpha-numeric pages that have been received or sent. The message list object 
stores a list of messages, including email or Short Message Service messages, and includes methods to view, store, 
edit, delete, and send messages. The message list may be embedded in a page and activated by the appropriate URL 
of the message protocol. 

[0141] The main content handler 114d is primarily a front-end for the HTMLp content handler 114c in that it uses 
^5 HTMLp to display a main screen for the wireless communication device 100. 

[0142] The advert content handler 114a is a front-end for the HTMLp content handler 114c that chooses which 
advertising page to display when the wireless communication device 100 is idle and instructs the HTMLp content 
handler 114c to display it. In addition, it intercepts keystrokes and user interface gadget activation to optionally delete 
an advertisement that has been responded to or expired. 

30 

a) Baste Content Handler API 

[01 43] Like protocol handlers 112, content handlers 114 have a well-defined interface the shell 106 uses to commu- 
nicate with them. The interface is tailored around the screen display 135 in the sense that there the content area is 
35 defined within the screen displayand interaction needs of content handlers 114. The four functions each content handler 
114 supports are: 

[0144] ContentOpen : This is the call that gives a content handler 114 control of the content area 214 of the screen 
display 136, the softkeys 130 and softkey labels 216, title bar 210, and status message area 212. Each content handler 
114 receives the following four pieces of information when its ContentOpen function is invoked: 

40 

1 . A stream of data returned by the protocol handler 112 that fetched the data; this is data to be displayed. 

2. A handle to the content area 214, indicating where the data is to be displayed. 

3. A flag indicating whether the content handler 114 has previously displayed this data 

4. A pointer to extra data that was passed by whatever entity asked the shell 1 06 to fetch the URL, allowing the 
^5 extra data to be entered into the page being displayed. 

[01 45] The use of the extra data is further described below with respect to the 

<TEMPLATE> tag of HTMLp and the "extra" protocol. 
[0146] ContentClose: When the user asks to close a page, or asks to open a different page, the current content 
so handler 114 is closed. It receives a flag that indicates whether the page is maintained in the URL history stack 108, or 
if it has been removed from the stack pemrianently. 

[0147] ContentProcessKey: In the absence of anything else to process a keystroke, the shell 106 delivers the key- 
stroke to the current content handler 114 by default. The current content handler 114 is the one displaying the content 
whose URL is at the top of the URL stack. 
55 [0148] ContentActivate: When the user presses a softkey 130 or selects an item from a menu, the string that is bound 
to the key or menu item is passed to the current content handler 114 via this function. In some cases, the string will 
be a URL that can be passed straight to the shell 106 to be fetched. In other cases, the string is an indication of what 
the user wishes to do, and the content handler 114 may perform the action rtself, or it may use an item the user has 
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selected on the screen display 136 to generate a URL it can give to the shell 106. For example, if the user selects an 
entry in the phone book and presses a softkey 130 labeled "Edit", the HTMLp content handler 114c will take the string 
associated with that softkey 1 30 and pass it to the embedded phone book object, which will use the string as a template 
for generating the actual URL to pass to the shell 106, based on which phone book entry the user has selected In the 
5 embedded object. 

[0149] The specific functionality of the content handlers 1 14 Is further described below. 

3. Control Flow 

10 [0150] A preferred implennentatlon of the browser 107 Is organized around a single callback queue 110, which takes 
the place of the event loop used in other environments. Any part of the MM 1 102, can request that a function be called 
at a later time by adding a function request to the callback queue 110. 

[0151] The callback queue 110 has a number of elements, each of which has a pointer to a function to call, and two 
32 bit arguments to pass to the routine. The function pointer can be to any module in the system. 
15 [0152] Essentially, the overall system executes a top most control loop: 

1. Call the next item on the callback queue 110. 

2. Update the screen display 136 with any changes that call made. This step Includes drawing graphical elements 
to the screen (e.g. scrolling, updating status messages and Icons) displaying keystrokes, and displaying new pages 

20 in response to user activation of functions or features associated with URLs. 

3. Go to step 1 . 

[01 53] Items for the callback queue 110 are added phmarity by asynchronous events such as keystroke (up or down), 
change in an active call, timer expiration, and Incoming text messages. 
25 [0154] Certain protracted operations also will use the callback queue 110 to continue the operation, while still allowing 
other actions (such as user input) to be handled. For example, reading the frames of an animated GIF Image is broken 
into two conceptual phases: 



30 



35 



1 . Read the first frame and queue a call to read the next frame. 

2. Attempt to read the next frame. If successful, queue a call to read the next frame. 

[0155] In this way, a page containing the animation can be displayed as soon as possible while the rest of the ani- 
mation is effectively loaded in the background. 

4. The Shell 



[0156] The shell 106 provides handling of input keystrokes and other inputs from the lower layers, and passing of 
such inputs to the appropriate protocol handlers 112 and content handlers 114. A list of shell 106 functions is provided 

to in Appendix A. 

a) Keypad Input 

[0157] Keypad input arrives spontaneously at the shell 106 from the portability layer 118. The shell 106 maintains a 
t5 keystroke target list which is a list of entities, particularly user interface objects of the currently displayed page, that 
can process the keystroke. When a keystroke arrives, the shell 106 passes the keystroke to the first entity in the 
keystroke target list, via ShellProcessKey. If that entity decides not to process the keystroke, it calls the shell 106 to 
give the keystroke to the next entity in the list (ShellPreviouslnput). The final entity in the list, placed there by the shell 
106 when the list is initialized, disperses the keystroke to the current content handler 114, which can choose to pass 
'*o to a default processing routine in the shell 1 06 that implements system-wide keystroke defaults, or the current content 
handler 114 can handle the keystroke as desired. 

[0158] The shell 106 includes functions to register an entity (usually a user interface object) Into the keystroke target 
list (ShellGrabtnput) and release an entity from the list (ShellReleaselnput). 

•5 b) Softkes 

[0159] One type of key that has a special function is a softkey 130, which is a key whose label is displayed on a 
page in the screen display 136, and whose purpose changes from page to page, according to defined parameters in 
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the user interface definition files 104. The shell 106 manages a nunnber of softkeys 130, typically between one and 
three, but variable depending on the wireless communication device 100. Each softkey 130 may be bound to a string, 
or to a menu whose menu items specify a string, or the softkey 130 can be set to pop one or more entries from the 
URL stack, or to do nothing. 

5 [0160] When a softkey 130 or a menu Item that is bound to a string is activated, the string is passed to the current 
content handler 114 via its ContentActlvate function. In some cases, the string that is bound to a softkey 130 is a URL 
to be fetched. In this instance, the URL is passed by the content handler 114 to the shell 106 for processing 
(ShellGetURL) and fetching by the appropriate protocol handler 112 and content handler 1 1 4. In other cases, the bound 
string is a command that the content handler 114 handles itself without changing pages. Finally, the bound string may 

'0 be a mixture of the two: a template URL (see below) that is modified by the content handler 11 4, based on some Input 
from the user, before being fetched. 

[0161] As noted above, as part of its Con tent Activate function, the HTMLp content handler 114c passes a string 
bound to a user selected user interface entity to any embedded object in the current page before it examines the string 
itself. Some embedded objects simply take commands to operate on what data they are displaying in this way, while 
15 others look for special escapes in the string to substitute some portion of the data the user has selected^ yielding a 
URL that they then pass to the shell 106. The HTMLp content handler 114c also has certain special commands rt 
accepts, rather than just accepting URLs from hyperlinks. 

c) URL Processing 

20 

[0162] The step of updating the screen display 136 in the above described control flow, when done in the context of 
obtaining a new page for display, is accomplished by passing a URL to the shell 106 via the ShellGetURL function. 
Fig. 4 illustrates the URL history stack 108 used by the shell 106 to support URL processing. The URL history stack 
108 is a LIFO stack. Each entry 402 includes a URL 404, a pointer 406 to a function table 412 for functions for the 
25 particular content handler 114 that handles the URL, extra data 408 (if any) that was passed in with the URL to be 
retrieved by the "extra" protocol or to be used by the content handler for the URL, a pointer 410 to the next URL, a 
privilege level 414 at which the page is operating, the priority 416 of the URL, and a pointer to the state block 418 the 
shell 106 maintains on behalf of the content handler 114. 

[0163] Referring to Fig. 5 there is shown a flowchart of the operation of the shell 106 in handling a URL. The shell 

30 106 extracts 500 the first part of the URL string, before the first':' character, and compares 502 it to the list of known 
protocol handlers 112 to Identify the appropriate-handler for fetching the URL data. If no protocol handler 112 is found, 
then the shell 106 creates 508 a complete URL by calling the BuiidURL function of the protocol for the URL currently 
at the top of the URL stack, passing it the current top URL and the URL that is being fetched. The protocol handler 
112 retums the absolute URL that should be used in place of the relative one that was passed in. 

35 [0164] If a protocol handler 112 is found, the shell 106 calls 504 the GetURL function of this protocol handler 112, 
passing the remainder of the URL. The protocol handler 112 is expected to fetch the URL, and return a pointer to a 
ContentStream structure that includes a string indicating the type of data returned, the privilege level at which the data 
should be interpreted, and a pointer to a Stream, which contains the actual data (the data need not be present yet, but 
reading from the stream must retum the data as it arrives) . If no stream is returned 506, the shell 1 06 returns 51 0 an error. 

40 [0165] The shell 106 matches 512 the data-type string against the list of known content handlers 112. If there is no 
match, the shell 106 retums 520 an error. If there is a match 514, this content handler 114 becomes the current content 
handler. The shell 106 resets 516 the softkeys 130, content area 214 size, title bar 210, and status message area 212 
to their default state. The shell 106 invokes the ContentOpen function of the current content handler 114, passing both 
the ContentStream and control of the content display area 214 to the current content handler 114 for the content to be 

45 displayed. 

[0166] If the open call is successful 522, the shell 106 updates the URL history stack 108, placing the URL, the 
pointer to the current content handler 114 functions, any extra data, on the stack, and returns 524 success to the entity 
requesting the URL, otherwise, the shell 106 reopens 526 the previous URL from the URL history stack 108, and 
retums an error. 

so 

5. Security 

[0167] Because content that is received over the air is allowed to activate telephone features and access telephone 
data, such as telephone book entries, the present invention provides mechanisms for security to prevent unauthorized 
55 access to functions or data. 

[0168] When a URL is fetched by a protocol handler 112 as part of its GetURL function, its data are assigned a 
privilege level by the protocol handler. If content comes from a privileged source, the protocol handler 112 assigns the 
highest privilege level. For example, all pages from the user interface definition files 104 which are stored in the ROM 
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126 of the wireless communication device 100 are assigned the highest privilege level. Fomnatted text messages, 
whether received or created by the user, are assigned a lowest privilege level. Content that does not have an assigned 
privilege level is automatically given the lowest privilege level by the shell 106. For example, content from the World 
Wide Web (unless otherwise preassigned) is given the lowest privilege level. The privilege level of an item of content 

5 is stored with its URL in the URL history stack 108. 

[01 69] Selected functions of the wireless communication device 100 are configured to be privilege-sensitive by either 
the manufacturer of the wireless communication device 100 or the service operator. When such a function is called it 
determines the privilege level of the page requesting the content from the page's URL In the URL history stack 108. If 
the privilege level of the requesting page is higher than the privilege level of the requested content, then the content 

10 is accessed. If the privilege level of the requesting page Is lower than the privilege level of the requested content, then 
the function can either deny the access out of hand, or confirm the operation with the user. For example, if a lower 
privilege page requests to make a telephone call via the CallManager, the user is alerted to the actual number being 
dialed and must confirm the request before the phone is dialed. 

15 6. The Content Handlers 

[0170] The following sections outline how the individual content handlers 114 Implement the four functions in the 
API to each content handler 114. 

20 a) The HTMLp Content Handler 

(1) HTMLp API 

[0171] The HTMLp content handler 114c provides a fully HTML compliant parser, using the HTML 3.2 specification. 

25 This parser is activated as needed by the HTMLp content handler 114c during parsing of a page of content to create 
user interface entities for display of the screen display 136, and for storing respective data associated with such entitles, 
such as labels, and associated data, including URLs to be fetched when the user interface entity is selected. 
[0172] As noted above, each content handler 114 provides an external interface of four functions, HTMLpOpen, 
HTMLpClose, HTMLp Activate, and HTMLpProcessKey. HTMLpOpen and HTMLpClose are described here. For ease 

30 of understanding, HTMLpActlvate, and HTMLpProcessKey are described below, after a description of the new tags of 
HTMLp. 

(a) HTMLpOpen 

55 [0173] This function, called by the shell 106, gives control of the content area 214 of the screen display 136 to the 
HTMLp content handler 114c for displaying a page of content. As noted, the HTMLp content handler 114c receives 
from the shell 106 a stream of data to display, a handle to the content area 214, a display flag indicating whether the 
content data (the page) has been previously displayed, and a pointer to any extra data to be associated with the page. 
[0174] The function determines from the display flag whether the page has been previously displayed, and if so, 

w whether any embedded object In the page was cached. In this case, the page is redisplayed and any embedded object 
has a RestoreState function called to reestablish its previous state. 

[0175] If the embedded objects for a page were not cached, or this is the first time the page is being displayed, the 
content stream for the page is passed to the underlying HTML parser to be interpreted as HTMLp code. The parser 
will create windows, and user interface entities as needed, and wrap text and update and assign soflkeys 130 as 
necessary. When the page has been completely parsed, it is displayed to the user. In creating the user interface entities, 
the HTML parser establishes a table of associations between the user interface elements (including keys 132, softkeys 
130, menu items, and the like) and URLs (whether local or remote) bound to these entities. The association identifies 
each particular user* interface entity, and a URL that Is to be fetched If the entity is selected or otherwise activated by 
the user These associations are used when subsequently processing key strokes received by the page by the HTM- 
'O LpProcessKey function. A handle to the main window that holds all the other pieces of the page is set as a state block 
418 for the page via a call to ShellSetState. 

(b) HTMLpClose 

'5 [0176] This function is called when the user closes the current page or switches to a different page. The shell 106 
passes in a flag indicating whether the page is to be removed from the URL history stack 108, or if it may remain on 
the URL history stack 108. If the page is not to be removed, and the page has not been marked as non-cacheable. 
then the main page is set not visible, effectively hiding it from the user, but maintaining it as an active page. 
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[0177] If the page is non-cacheable or the page is to be removed from the URL history stack 108, the page window 
and its associated data structures are destroyed. A page is deemed non-cacheable when it refers to data outside itself 
that could potentially change while the page is not displayed. For example, if the page contains an <INC> ("Include") 
tag or uses the configuration mechanisms described below to display a configuration setting, it is considered non- 
cacheable. The use of the conditional <IF> tag, and the <TEMPLArE> tag may or may not cause a page to be non- 
cacheable, depending on whether the DYNAMIC attribute for these tags is set and whether a %[i/r/| escape is en- 
countered inside a <TEMPLATE> </TEMPLATE> block. These features are further explained below. 

(2) Extensions to HTML: HTMLP 

[0178] The present invention provides an MMI 102 that is fully HTML compatible. However in addition to merely 
displaying content, It is desirable to provide a set of HTML extensions for further refining the user interface of a wireless 
communication device 100, making it more functional for telecommunication functions and the small screen display 
136, and allowing the wireless communication device to be easily and quickly customized by both the device manu- 
facturer and the service operator. 

[0179] The extensions which make up HTMLp are as follows: 
(a) A. User Interface Extensions 

[0180] In this section, the extensions of HTMLp which enrich the user interface are described. These various tags 
are decoded by the HTMLp content handler 114c when it receives a page of content from the shell 106. 

(i) Binding Keys to Functions: <KEY> Tag 

[01 81 ] A typical wireless communication device 1 00 possesses one to three softkeys 1 30, the standard number keys 
134, and a number of special-purpose keys 132. A new extension of HTMLp allows any key of the keypad 128 to be 
bound by an HTML page using the <KEY> tag. The syntax is: 

<KEY KEY=key LABEL=string ACTION=uryiPOPIDONEICLEARIMENUIGOINOME> 
[0182] The value of the KEY attribute is one of the following: 

1 ,.../77 Specifies a softkey to be bound. Keys are numbered from left to right, or from top to bottom (depending on 
where they are on the phone). Typically (m<=3), but this may be varied per device. 

send Specifies the "Send" or 'Talk" key. 

back Specifies the "Back" key. Not all devices have this key. A page must be privileged to bind this key. 

#n Specifies one of the dialing keys, where n is the label on the key (0-9. or #). To bind ail dialing keys to 

the same action, specify #x. 

end Specifies the "End" key. A page must be privileged to bind this key. 

mode Specifies the "Mode" or "ABC" key. 

clear Specifies the "Clear or "Del" key. 

up Specifies the up-arrow key or down action. 

down Specifies the down-arrow key or down action. 

left Specifies the left-arrow key. 

right Specifies the right-arrow key. 

select Specifies the select key or action. 

power Specifies the power key. A page must be privileged to bind this key 
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default Specifies an action for any key for which no other action has been specified, with the exception of the back, 
end, and power keys, for which actions must always be explicitly specified, if any other than the standard 
actions are to be taken. 



5 [0183] If the key is a softkey 130, the value of the LABEL attribute is the string that appears fn the on-screen label 
for the key. If the string is too long to fit in the space allotted, it is truncated. The LABEL attribute is valid only for softkeys 
130. 

[0184] The value of the ACTION attribute specifies what should happen when the bound key is pressed. The possible 
values are: 

10 

URL Specifies a URL to be fetched, or some other command for an embedded object in the page. The URL is 
passed to the HTMLp content handler's HTMLpActivate function for processing. 

POP Requests that the previous page be displayed. 

DONE Requests that the page before the most-recent <TOP> page be displayed. 

CLEAR Requests that all pages be cleared from the URL history stack 108 and the main screen be displayed. 

MENU Specifies that the softkey 130 should bring up a menu. The items in the menu are specified by <KEYMENU> 
tags in the <HEAD> section. This is valid only for softkeys 130. 

GO Asks that the currently selected link be fetched. This is valid only for pages with the <LINKMENU> attribute. 

?5 NONE Asks that no action betaken when the key is pressed. This allows the default action for the keyto be overridden. 

[0185] When the HTMLp content handler 114c loads a page with the <KEY> tag, it creates a key binding table that 
stores the association between the key, label (if any) and action. 

[0186] The string bound to the ACTION attribute is processed by the HTMLpActivate function, as follows. 

w 

(if) HTMLpActivate 

[0187] The HTMLpActivate function is used to detemrime the appropriate response to the string that Is bound to a 
user interface entity, such as a key, softkey, menu item, hyperiink, or the like. The input is a string from the shell 106, 
f5 and more particulariy, a string that is bound to the ACTION attribute of a KEY or KEYMENU tag, or the HREF attribute 
of an A tag. The new HTMLp tags generally allow any key or menu item of the wireless communication device 100 to 
be associated with a specific action or URL. 

[0188] Referring to Figs. 6a-6b, there is shown a flowchart of one embodiment of the HTMLpActivate function. The 
HTMLp content handler 1 14c maintains a list of embedded objects in the current page. If there is an embedded object 
0 in the page (602), the function passes the string to the embedded object for processing 604. The embedded object 
returns a Boolean Indicating whether the string was processed, and that no further processing of the string is necessary. 
If the string was processed by the embedded object (606), then the function returns 608 control to the shell 106. The 
processing 604 of a string to an embedded object is further described below. 

[01 89] If the string was not processed, the HTMLpActivate function proceeds to process 610 the string according to 
5 its value as an ACTION attribute. 

[0190] If the string is "POP," (612) then the shell's ShellGoBack(POP) function is called 614. This function pops the 
top URL of the URL history stack 108, and cause the previous URL to be loaded. 

[0191] SImilariy, if the string is "DONE," (616) the ShellGoBack(DONE) function is called 618, which is similar, but 
displays the page before the most recent <TOP> tag; the <TOP> tag identifies the first part of a multi-part form, as 
0 further described below. 

[0192] The HTMLp content handler 114c maintains a pointer to a current object in the page, which can be an input 
field in a form or a hyperlink. This current object is where the input focus is located. 

[01 93] If the string is "GO, " (620) and the current object is not a hyperlink (622), then nothing happens. If the current 
object is a hyperlink, the content handler 114 gets 624 the URL string associated with the hyperiink, and passes that 
5 URL string to ShellGetURL, which then fetches the actual content. 

[0194] If the string is "CLEAR," (626) then the SheHGoBack(CLEAR) of the shell 106 is called 628. This function 
clears the URL history stack 108 and causes a default main page to be displayed. 

[01 95] If the string has the form "reset form/d," (630) then the function returns 632 the input elements of fonm number 
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formidXo their original state. This action is bound to any softkey 130 or softkey menu for an <1NPUT TYPE=reset> 
gadget. 

[01 96] If the string has the form "submitfc>r/n/£/,/a/3eA" (634) then the function submits 636 form number formid ac- 
cording to the METHOD and ACTION attributes of the FORM tag that defined fomn number formid. If present, tabel 
indicates which <INPUTTYPE=submit> gadget the user activated, so its name-value pair can be submitted along with 
the values from the rest of the gadgets in the form. 

[0197] If the string is "SELECT", (638) then the function activates 640 the user interface gadget the user has selected, 
according to the gadget type as follows: 



<INPUTTYPE=radio> 


Selects that radio button and unselects other radio buttons with the same name. 


< IN PUT TYPE=checkbox> 


Checks or unchecks the checkbox. 


<SELECT> 


Ifthe options are displayed, it choose 3 the option the user has selected. If the SELECT 
list is a pop-down list, the pop-dowr. is closed. 


hyperlink 


Follows the link. 
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[0198] If the string is "NONE" (642), then no action is taken. 

[01 99] After all these conditionals are passed, if the string is any other value (644), such as a URL, then it is passed 
646 to ShellGetURL to be processed. If the URL has no arguments (there is no *?' in it), any parameters that were 
passed to this page as extra data are also passed in the call to ShellGetURL. 

[0200] An example of the HTM LpActivate function and its particular benefits for embedded objects is further described 
below. 

[0201] An example of processing by the Activate function using the <KEY> tag is as follows. Assume that a page 
contains the following KEY tag: 

<KEY KEY= "sencf ACTiON=phone:dial> 
[0202] When this page Is loaded, the HTMLp content handler 114c stores the association between the Send key 
and the U RL "phoneidial" in its key binding table. This stored data will be used to activate the telephone dialing function 
of the telephone protocol handler 112g when the user presses the Send key. The HTMLp content handler 114c is the 
current content handler 114. 

[0203] Assume^ that at some later point the user presses the Send key. The portability layer 118 calls the shell's 
ShellProcessKey function indicating that a key has been pressed, and passes in a key number for the Send key, and 
a flag indicating that it has been pressed. As noted above, the shell 106 maintains the keystroke target list. The Shell- 
ProcessKey sends the received key to the first target on the stack. If this target does not have a purpose for the key, 
then the target calls the Previouslnput function of the shell 106, passing the Send key index. The shell 106 finds the 
next Item on its keystroke target list. This process repeats until the key is passed to the HTMLp content handler 114c. 
This happens when the shell 106 calls the ProcessKey function of the current content handler 114, since the URL at 
the top of the URL history stack 108 contains the pointer 406 to the HTMLp content handler 114c. 
[0204] The shell 106 then calls the HTMLpProcessKey("Send"). This function looks at the key binding table, which 
includes the association between the Send key and the URL "phoneidial." The HTMLp content handler 114c calls 
ShellActivate(phone:dial), which calls the HTMLp content handler's 114c HTMLpActrvate function. 
[0205] Here^ it is assumed that there is no embedded object in the page. The function then tests the Input string 
against the various other actions, such as POP, DONE, GO, CLEAR, and NONE. Since the string "phoneidial" does 
not match any of these, the HTMLpActivate function calls the shell's ShellGetURL(phone:dial) function. 
[0206] The shell 106 processes this function, as shown in the flowchart of Fig. 5. Continuing the example, the shell 
determines that the URL is for the telephone protocol handler 112g, and passes the "diar portion to it for processing. 
This protocol handler 112g returns a content stream of type "Call Manager" (destined for the call manager content 
handler 114b) that contains the number to be dialed. The shell 106 closes the HTMLp content handler 114c, but does 
not remove the URL from the URL history stack 108. The shell 106 places the URL "phone:diar on the top of the URL 
history stack 108. The shell 106 gets from the content stream returned by the telephone protocol handler 112g the 
string name of the content handler 114 to handle the stream. The shell 106 looks up the string in its table, and updates 
the CONTENT field of the top entry of the URL history stack 108. Finally, the shell 106 invokes the Open function of 
the new current content handler 114, passing in the content stream data. In the Open routine of the call manager 
content handler 114b, it retrieves the phone number from the stream and invokes the necessary function in the tele- 
phone control module 120 to establish the phone call. 
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(iii) Building Menus 



[0207] If a softl<ey 130 Is bound to a menu using the <KEY> tag, and ACTION="menu", then the entries for the menu 
are specified using a <KEYMENU> tag in the HEAD section of the page. The <KEYMENU> tag has the following syntax: 
5 <KEYMENU KEY=n LABEt=stnng ACTION=u/-/IPOPIDONEICLEARIGO> 

[0208] Entries are displayed in'the menu in the order in which they are encountered. However, menu entries do not 
all have to be together in the header. 

[0209] The value of the KEY attribute specifies to which menu the entry should be added. 
[0210] This is the same value as given for the <KEY> tag that specified a menu should exist. 
10 [0211] The value of the LABEL attribute is the string that appears in the menu entry. The menu will be as wide as 
necessary to hold all the entries. However, the label will be truncated if it is wider than the screen. 
[0212] The value of the ACTION attribute specifies what should happen when the entry is selected. The possible 
values are: 

'5 URL Specifies a URL to be fetched, or some other command for an embedded object in the page. 
POP Requests that the previous page be displayed. 

DONE Requests that the page before the most-recent <TOP> page be displayed. 

20 

CLEAR Requests that all pages be popped from the URL stack and the main screen be displayed. 

GO Requests that the currently selected link be fetched. This is valid only for pages with the <LINKMENU> at- 
tribute. 

25 

[0213] These ACTION attributes are processed in the same manner as the attributes of the <KEY> tag in the HTM- 
Lp Activate function, as described above. 

[021 4] Fig. 7 illustrates example of the HTMLp source code for page with a key menu defined, and the screen display 
136 when the menu is selected to be displayed. The HTMLp code is shown on the left, and the resulting page on the 

30 right. Line 4 defines a menu for the first softkey (KEY=1) Note that when the menu is open, the softkey label 216 for 
the menu changes to "Select," indicating that if the user presses the softkey 130 again, the selected entry will be 
activated; this label 216-may change to instead close the menu, leaving the Send key to activate the selection. Lines 
5-7 define the menu items for this menu, each of which has Its ACTION attribute specifying one of the user interface 
definition files 104 for the appropriate page to display to retrieve messages, recent calls, or phone settings. Selecting 

?5 one of the entries in the menu, either by pressing the softkey marked "Select" or pressing the numbered key matching 
the icon to the left of the entry, causes the ACTION specified In the KEYMENU to be executed. In this example, the 
appropriate HTMLp user interface definition file 104 is fetched from ROM. 



(IV) Delayed Help 

[0215] Many user interfaces for computers provide some fomri of online context-specific help text. Conventionally, 
these help screens are displayed in their own window overlaying the portion of the user interface where the user is 
expected to enter data. In addition, help screens are typically passive, and appear only in response to a direct action 
of the user to request help. However, in a wireless communication device with a very small screen display, overiaying 
a help screen over the content area would hinder the user. In addition, since the user may not know that help is available, 
passively waiting for the user to request help may be insufficient to assist some users. 

[0216] To assist users who might be uncertain of what to do next when viewing a page, and to provide such help 
without obscuring the content area 214 of a page where the user is expected to input data, the present invention 
enables help text to automatically scroll across the screen in place of the title 210 of a page after a certain amount of 
time has elapsed without a user input keystroke. More than one help text string may be specified, in which case the 
strings are displayed in succession, with a suitable interval between each one. The help text strings are displayed only 
once each, each time the page is viewed. 

[0217] To allow pages to specify one or more help strings a new <HELP> tag is specified in the <HEAD> section of 
the document. The syntax of the <HELP> tag is: 

<HELP>/?e/p sfr/>7p</HELP> where heip string is the help text to be displayed. 
[0218] When a page containing the <HELP> tag is loaded, the HTMLp content handler114c builds a structure, such 
as a table, that includes the help text strings. This table is passed to the shell 1 06, which stores the table for later use. 
The functionality of <HELP> tag is then handled primarily by the shell 106 during idle time processing. 
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[021 9] The she!! 106 maintain a counter of the number of seconds since the last keystroke. The counter is nonnally 
cleared on each ShellProcessKey. The real time operating system 122 has a timer that runs in the background, and 
calls a routine in the shell 106 that increments the counter. If counter reaches a threshold number of seconds, the shell 
1 06 creates a scrolling banner object, and instructs it to display the first help text string in the table. The scrolling banner 

5 object internally determines when the help text string is fully scrolled off of the screen display 1 36, and notifies the shell 
106, which redisplays the title 210. A second threshold is set for displaying the next help string. The thresholds are 
predetermined by the shell 106 based on a desired length of time for displaying the help text strings. 
[0220] Fig. 8 shows an example of the HTMLp source for a page including two HELP tags, and the resulting sequence 
through which the screen display 136 passes when the page is loaded. Lines 7-8 of the HTMLp code define the help 

10 text to be displayed. The second and third screen images show the first help text string being scrolled in place of the title. 

(v) Pages as Templates 

[0221] There are a number of extensions of HTML in the present invention that allow pages to be designed using a 
15 standard HTML editor, using arguments passed by C code to complete form entry fields, or specifying data to be fetched 
on the fly from the device to determine the initial state of a form in a page. These extensions include templates, con- 
ditional HTML: configuration setting capabilities, and "included" HTML. 

[0222] Generally, the C code for an embedded object has parameters to be displayed, but it is desirable that the 
format of the display be defined In the HTML for the page. For example, a page displaying a form of data for an incoming 

20 call preferably displays a telephone number and its associated name. Accordingly, the HTML page for displaying the 
incoming call should be able to take the parameters (telephone number and caller name) andformat them as necessary. 
[0223] However, conventional HTML 3-2provides no mechanism to pass data directly into a page for this desired 
application, but rather at best allows the HTML for the page to be created on demand. The generation of HTML is both 
slow and compute-intensive, and the executable scripts for generating a page typically require more storage than the 

25 page being generated, thereby making it less efficient than storing the page itself. By allowing indirect passing of 
arguments, the present invention eliminates the need to generate HTML at run time. This enables the pages to be 
stored in the ROM 126, and requires less memory than the code for generating the HTML on demand. 

(a) Using Pages as Templates 

SO 

{0224] The first extension which enables data to be passed into a page is the <TEMPLATE> tag. The <TEMPLATE> 
tag may appear anywhere in page. It must be matched by a corresponding </TEMPLATE> tag at the appropriate place 
in the structure of the document. 

[0225] All text between the <TEMPLATE> and <:/TEMPLATE> tags is examined for escapes of the form %(ur/), % 
35 [urf\ or %<url>. This includes text within tags, even within quoted attribute values. When such an escape is seen, the 
data for the URL are fetched and, if they are plain text or HTML, they are inserted into the HTML document in place 
of the escape exactly as If they had been there all along. To include a % character in the text between <TEMPLATE> 
and </TEMPLATE>, it must be preceded by another %, as in "%%". 

[0226] The form %<urf> causes the text returned as the data for ur/to be encoded for use as an argument for another 
40 URL. URL arguments have a restricted character set, with anything outside that character set being encoded as % 
followed by two hexadecimal digits. 

[0227] The distinction between %(urf) and %[L/r/| lies in the caching behavior of the HTMLp content handler 114c. 
Nomnally, the data for a page are parsed and the information needed to render the page is saved so long as the URL 
remains on the URL history stack 108. This allows for quick redisplay of a page that has already been fetched. If, 
45 however, a escape is seen in a template section, it indicates that the data for the URL are dynamic enough to 

warrant the reparsing the page when It needs to be redisplayed, to catch any changes in the URL data since the user 
last saw the page. 

[0228] Fig. 9 illustrates an example of the TEMPLATE tag. In this example, the text between the <TEMPLATE> tags 
on lines 1 9-25 defines the template text; the escape on line 20 results in the URL "extra:name" being fetched, which 
so replaces the text with whatever data is stored under the variable "name". The screen display shows this as the text 
"Adam M." 

[0229] The HTML 4.0 specification provides for the use of embedded objects in pages. Generally, an embedded 
object is an item of code positioned at a location on the page that is responsible for constructing and displaying its own 
content. An embedded object is specified in the URL for the OBJECT tag, located in the desired positron in the HTML 
55 source. Normally, the URL specifies a code entity such as an ActiveX control, a Java applet, C code, and the like. In 
the HTML 4.0 specification, the URL is merely passed to a server which return the desired entity. However, in HTML 
4.0 once a page with an embedded object is loaded, no further processing or passing of arguments to the embedded 
object can occur. In particular, when a user selects a hyperlink (a user interface gadget associated with a URL) on a 
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page containing the embedded object, the embedded object does not have any opportunity to process the URL, and 
instead, the URL is merely followed to the linked page. 

[0230] However the present invention extends the functionality of embedded objects by providing URL associated 
with a hyperlink or user interface gadget first to embedded objects for processing. This lets an embedded object respond 
5 directly to arguments provided in HTML forms, without having to have the server update the page. The implementation 
of this embedded object functionality is provided in the HTMLpActivate function of the HTMLp content handler 114c, 
as described above with respect to Fig. 6. 

[0231] As described, when the HTMLp content handler 114c processes a string that is a URL, if there is an embedded 
object in the page, the HTMLp content handler 114c passes the URL to the embedded object. In accordance with the 
10 present invention, an embedded object does one of three actions in processing a URL: 

• Process the URL as a command; 

• Look for escape sequences in the URL and substitute for those sequences information from the data the user 
selected, before passing the URL to the shell 106 to be fetched; or 

'5 • Return the U RL to the HTMLp content handler 1 1 4c without processing, to be processed according to the remainder 
of HTMLpActivate. 

[0232] As an example of the second type of processing, an instance of the phone book embedded object in an 
HTMLp page may look for escape sequences such as "@n" or"@/" to replace with the name or record ID of the phone 

20 book record the user has selected. The phone book object includes an edit method that can edit either the name of a 
record, or any of the fields. Passing the URL "phone:edit?Name=@n" to the phone book object will begin the process 
of adding another number to the selected phone book record by entering the phone book entry creation process with 
the name already set from the selected phone book record;, passing the URL "phone:edit?id=@i" to the phone book 
object will edit all the fields of the record. 

25 [0233] The advantage of this extended functionality is that instead of having pages hardcoded in C, they can have 
those elements that require the data access and dynamic behavior of C be coded in C, while the specification of 
functions the usercan perform is done in HTML. This is not possible in HTML4.0 because the only way foran embedded 
object to interact with the user is by putting up its own user interface, which again will be hardcoded in the language 
in which the embedded object is implemented, and thus not easily modified or branded by the service operator 

30 [0234] Figs. 10 and 11 provide two examples of possible phone book pages, and Illustrate the flexibility embedded 
objects can provide with the extended processing of the present invention. 

[0235] - In Fig. 10, the user can create a new entry, or modify one of the fields of an existing phone book entry to 
change its speed dial key, ring tone, or number Line 5 defines a key menu, which is shown displayed, activated by 
the user pressing the first softkey 1 30. The menu entries (lines 6-12) are bound to URLs that have escape placeholders 
35 for data from the current selection. In particular, line 6 defines the ACTION for the menu item to be a URL for the 
embedded phone book object that will change to the first page of the phone book entry creation process with the name 
already specified to be that of the current selection in the embedded phone book object. Generally, other URLs in the 
present Invention can be activated using pieces of the selected phone book record to fill in their arguments; any of 
these URLs can be bound to menu entries, softkeys, or other keys on the keypad. The specific escape sequences are 
described below, with respect to the phone:list URL of the phone protocol. 

[0236] In Fig. 11 . the usercan create a new entry, or go to a separate page to display all the parameters for a particular 
entry, and change them if she wishes {this is done via a separate screen, pbedit.html; the @' escapes in the editurl 
argument to the phonerlist embedded object extract all the relevant pieces of the entry tor passing to pbedit.html). In 
addition, the a graphical title bar is used here, along with a tiled background of the wireless communication device 
manufacturer's logo as a border The object to embed is specified in line 10 with a URL to the phone list object. 
[0237] When the HTMLp content handler 114c encounters an <OBJECT> tag, ft requests the shell 106 to fetch the 
data associated with the URL given as the CODE attribute to the OBJECT tag. The shell 106 returns this data as a 
content stream, which must be of type "Objecr. In the stream is a structure that contains; 

• A pointer to the object (a window to be made a child of the HTMLp page window) 

• A pointer to a function HTMLpActivate can call with the string it hasbeen given. 
A pointer to a function that will fetch the current state of the object. This is called by HTMLpClose. 

• A pointer to a function that accepts the state that was fetched and restores the object to that state. This is called 
by HTMLpOpen when it is told the page has been displayed before. 

• A pointer to a function that returns the "value" of the object as a string. This is called when the object is part of a 
form that is being submitted. 

► A pointer to a function that accepts the "value" to which the object should set itself. The value is a string. The 
function is called when the object is part of a form and extra data that have the same name as the object (as given 
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by the NAME attribute to the OBJECT tag) were passed, 
(b) Accessing Device Settings 

5 [0238] The various configurable parameters of the wireless communication device 1 00 are accessible via the config 
protocol, further described below. It is desirable to provide pages that can adjust these settings using fomi gadgets to 
specify the possible values for each setting. However, to do this, it must be possible to set the initial state of these form 
gadgets to match the current value of the setting they're supposed to affect. 

[0239] The form gadgets most preferably used to set the value of a device setting are the radio button, the checkbox, 
10 and the scrolling list. The radio button and checkbox are both accessed via the INPUT tag, with a TYPE attribute of 
either RADIO or CHECKBOX. For these input elements, it is possible in HTML 3.2 to specify a selection attribution 
which defines whether the input element is selected on the form. The selection attributes include CHECKED and 
SELECTED. The CHECKED attribute indicates that a radio button or checkbox is to be initially selected. Similarly, a 
scrolling list is specified by a <SELECT> tag. with <OPTION> tags inside it, any of which may have the. SELECTED 
IS attribute to indicate that that option of the selection list should be Initially selected. 

[0240] Normally these attributes are Boolean; if the CHECKED or SELECTED attributes exist in the source, the radio 
button, checkbox, or option is selected, while if they do not, it is not selected. In the present invention, however, these 
attributes have been extended to accept a value. The value takes the form of an expression, which, rf it evaluates true, 
causes the item to be selected initially. 
20 [0241] The expression fetches data from a URL and either treats it as a Boolean value, to be checked for truth or 
falseness, or compares it to a string for equality or inequality. 
[0242] The syntax is: 

ATTRlBUTE=[!]ur/ 

or 

^5 ATTRIBUTE=t/r{!]=sfr/n5f 

[0243] ATTRIBUTE is either CHECKED or SELECTED. The URL here is to a config protocol, and takes the form 
"config :se///np" where setting is the particular setting of interest which the config protocol handler 112b will access. 
[0244] The first syntax form treats the fetched URL data as a Boolean value, converting the text to an integer and 
seeing if it is 0 or non-zero. If the leading "I" is present and the value is 0, the item is selected, while if the leading 

30 is absent and the value is non-zero, the item is selected. If the uri itself contains an equal sign, it must be enclosed in 
parentheses. 

[0245] The second syntax form performs a string comparison between the string and the data retrieved for the URL. 
If "l=" is given, the item is selected if the strings are not equal, while if just = is given, the item is selected if the strings 
are equal. 

35 [0246] If the data returned by the URL is neither plain text nor HTML, the expression always evaluates false and the 
item remains unchecked. 

[0247] Fig. 12 provides an example of the use of this extension, showing both the HTMLp source, and the resulting 
page. Lines 9-1 4 specify the various configuration settings, showing the CHECKED attribute being set by an expression 
which is a URL to the config protocol hander. The illustrated page shows the'resulting user interface for configuring 

40 these settings. In this example, the user will be presented with three radio buttons and a text input field. The user will 
be able to specify whether the backlight for the screen display 136 should be on only when the device is in-use, or 
when ifs in-use or is plugged in, or not at all. In addition, the user can set the number of seconds without input after 
which the wireless communication device is consider to no longer be in use. These settings may be stored In the 
"backlight" and "backlight delay" settings, respectively. When the screen first appears, the radio button that corresponds 

45 to the current setting will be checked, and the text input field will contain the current delay 

[0248] Generally, when an <INPUT> tag with this extended selection attribute is loaded, the HTMLp content handler 
114c passes the URL to the shell 106 to be fetched. The HTMLp content handler 114c evaluates the fetched data 
according to its syntax form, as described above, and establishes the value of the selection attribute according to the 
evaluation of the URL data. "Including" HTML 

so "Including " is an extension to HTML that allows blocks of HTML or HTMLp code to be referenced in a page. Any 

included HTML is recursively resolved, so that included HTML may itself include other HTML. At present, the HTML 
4.0 provides no mechanism to include blocks of HTML from one page into another. A benefit of included HTML Is that 
common HTML components, such a page headers or footers, navigation toolbars, and the like, which are desired to 
appear in a number of pages, may be easily incorporated by a single reference to the included pages. 

55 [0249] The present invention provides a mechanism for including HTML (which also includes plain text) from any 
source, by giving its URL. This is used primarily to display device settings via template pages, but can also be used 
to reduce content size by placing elements common to multiple pages in a separate part of the content archive and 
including it in the other pages. The mechanism is provided by the <INC> tag, which has the following syntax: 
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<INC SRC=url DYNAMIC> 

[0250] The SRC (source) attribute must be present, and specifies the URL whose data are to be included in the 
document at that point. When the <INC> tag is resolved by the HTMLp content handler 114c, the data associated with 
the URL is fetched inserted at the location of the <INC> tag. 
5 [0251] An <INC> tag may be used anywhere In a page, except from within another tag. Forexample/'<A HREF=<INC 
SRC=file:commonurl.t>ct»" is not allowed. 

[0252] Fig. 13 illustrates an example of the <INC> tag. In this example, the first page infor.html has an <!NC> tag 
on line 2 referencing the second file bbody.html, which itself has an <INC> tag on line 8 referencing a third file stdlogo. 
html. When the first page is loaded, the HTMLp content handler 114c fully resolves all <INC> tags, and produces the 
10 resulting page, as shown. File info.html has an <INC> tag on line 13 which references the file endbody.html, and this 
latter file includes the </BODY> tag properly closing the <BODY> tag that appeared in a completely different file, bbody. 
htmh 

[0253] Generally, when parsing a page, as the HTMLp content handler 114c identifies an <INC> tag, it fetches the 
reference URL and directly inserts the data from the file into the source of the present file, and resolves it as needed 
15 for displaying the page. 

[0254] If the DYNAMIC attribute is specified for the <INC> tag, It causes the page to be rebuilt when the user returns 
to It, rather than using display instructions that were cached when the page was temporarily closed. In general, the 
DYNAMIC attribute indicates that the urf used as the SRC refers to data that may change while the page is temporarily 
closed, so it must be reread and the page rebuilt to accommodate any such change. 



(d) Conditional HTML 

[0255] The display of pieces of a template HTMLp page can be controlled by parameters passed with the URL for 
the template page, either directly as arguments following a '?' in a URL for the file protocol 11 2d (arguments specified 

^5 In a URL for the file protocol 11 2d are available as values within the file using the extra.protocol), as form data from a 
METHOD=NEXTfonn in the referring URL, or as parameters from C code in the present invention. 
[0256] Conventional HTML does not allow for conditional expressions to be encoded directly in the HTML source of 
a page to control which elements of the page are displayed. The present invention overcomes this deficiency with the 
new <IF> tag The <IF> tag allows for testing of expressions, such parameters or device settings, to control the display 

30 of a page. The syntax is as follows: 



[0257] The expression in the TEST attribute is evaluated exactly like that described for the CHECKED and SELECT- 
ED attributes, above. 

[0258] For example, consider the HTMLp source: 



20 



35 



<IF TEST=expression DYNAMlC>//f/7i/<ELSE 
TEST=expression>html<^ELSE>hrnil<^nT> 



to 
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<1F TEST=extra:conf> 



<KEY KJEY=1 LABEL=Confercnce ACTION=phone:conference> 



5 



<ELSE> 



<ICEY KJEY=1 LAJBEL="Pick Up" ACTION=phone:answer> 



</IF> 



10 



<KJEY KJEY=send ACTION=phone:answer> 



15 



20 



<IF TEST=config:anykey> 

<K£Y ICJEY=default ACTION==phone:answer> 
<1CEY KEY=back ACTION=phonc:answer> 



<ELSE> 



<ICEY KEY-default ACTION=none> 



25 



<KJEY KJEY-back ACTION=phonc:ignorc> 



</IF> 



[0259] In the first <IF> tag. TEST is evaluated with respect to extra data "conf being passed into the page by the C 
30 code that loaded the page. This data is stored in a variable available to the HTMLp content handler 114c. When the 
page is loaded, if "conf evaluates to TRUE, then the first softkey 130 (KEY=1) is labeled "Conference" and is bound 
in the key binding table to the URL "phonexonference", to allow the user to activate the conference feature of the 
telephone. If "conf evaluates to FALSE, then the softkey is labeled "Pick Up" instead and the key is bound to a different 
URL. 

55 [0260] In the second <IF> tag, the tested data is a configuration setting of the wireless communication device, ac- 
cessed by the "conf ig:anykey" URL. Depending on the device configuration for this setting, either all keys, including 
the Back key, will be bound to the "phoneranswer" function, or all keys but the Back key (and any other key that has 
a specific binding) will do nothing, while the Back key will be bound to the "phoneiignore" function. 
[0261] The <IF> tag has a DYNAM IC attribute that tells the parser that the URL rt uses generates dynamic data and 

40 the page should be reparsed, similar to the %[ur/] fomi used in template mode to signal that t/r/ refers to data dynamic 
enough to require the page to be rebuilt when it is again made visible. 

(vr) Phone Number Entry Field 

45 [0262] HTML 4.0 is designed as a general purpose language, and does not include any features that make It partic- 
ularly adapted for use in a wireless communication device, particularly one capable of making telephone calls, and 
storing telephone numbers and associated names. 

[0263] To make HTML more adapted for such a wireless communication device 100, the present invention specifies 
"phonenum" and "phonename" as new values for the TYPE attribute of the <INPUT> tag. Generally, <INPUT> tag 

so allows specification of a data input type, such as a checkbox, radio button, text, or image. 

[0264] The new input type of the present invention allows the user to enter a phone number or a person's name. As 
the user typeS: the input field uses the input data to look up a matching record in a phone book data structure. Matching 
records are then displayed in a list below the input field in exactly the same format as is used in the phone book display. 
Once the matching records are displayed, the user is able to select an item in the list, and have that item be used to 

55 complete the forni. 

[0265] More particularly, when the input type is "phonenum," the input digits are compared against all telephone 
numbers in the phone book; matching telephone are displayed in a list. When the user selects one of the matching 
telephone numbers in the list, this causes the input field to be replaced by the full selected telephone number, with the 
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portion that matched the input underlined. In matching, single digits (0-9) or double digits (00-99) are matched only 
against the speed dial list, and display matching speed dial numbers. 

[0266] When the input type is "phonename", the input characters are compared against the names in the phone 
book, and those entries that match are displayed, v/ith the characters that matched drawn underlined. Matches in the 

5 first word of the name take precedence over matches in subsequent words and the list is sorted accordingly. When 
the user selects one of the matching names, this causes the input field to be replaced by the full matching name. 
[0267] Fig. 14 illustrates an example of the HTMLp source and the resulting page. Here, line 7 specifies the phone 
protocol for dialing a telephone number; the input type is "phonenum". The user has first typed in "2" which is matched 
against the speed dial list and displays a matching name. In the next image, the user has typed in "995" which is 

10 matched against the phone book list, and displays a single matching name. In the third image, the user has selected 
the name, which causes the entire telephone number that matches including prepending and remaining digits to be 
inserted into to the input field for use in dialing. 

(b) Multi-part Forms 

15 

[0268] As mentioned earlier, in typical HTML pages destined for the desktop and its large screen, a conventional 
form will use many input fields. If such a form were displayed on the small screen display 136 of a typical wireless 
communication device 100, It would be very easy for the user to become lost in the form, because she loses the context 
of the form, most of which will be scrolled off the screen display 136 at any given time, or she cannot see much of the 
^ data being entered. Fig. 16 illustrates an example of a conventional HTML form which would be cumbersome to use 
on a screen display 136 of a wireless communication device 100. 

[0269] One solution is to break the single form into a series of forms that each gather one or two of the items required. 
In this case, however, conventional HTML requires the data from each form to be transmitted to the server as part of 
the URL that fetches the next form. The server then takes the data passed in the URL and returns a page that must 

25 be generated on-the-fly with the passed-in data from the previous forms included as "hidden" type input elements in 
the form in the returned page. In this manner, the data the user enters get sent up and back multiple times until the 
entire form has been filled in. This process is very bandwidth intensive, and time consuming, and costly. 
[0270] The other drawback to breaking a form into multiple forms is what the user has to go through if she decides 
in the middle that she does not want to complete the form after all. In such a case, the user has to hit the "End" or 

30 "Back" key once for each of the subforms that have been filled in, since each is a separate page. If the user is in a 
hurry, she could easily overshoot and end up dropping out of a place she actually wanted to be in when canceling the 
form. 

[0271] Figs. 17a and 17b illustrate a conventional multiple form method, as described above, where parameters 
received frorri a client computer in one HTML page are inserted by the server computer as HIDDEN type inputs in a 

35 next HTML page before being uploaded to the client computer. As seen in the figures, multiple pages have to be 
dynamically created to continually pass this data back and forth between the client and server 
[0272] This protocol for sending data back and forth between a server and a client results from a fundamental as- 
sumption of standard HTML that each transaction between a client and server is stateless, and thus, no data from 
previous states may be implicitly relied on to complete a current state. 

40 [0273] The present invention overcomes these deficiencies of HTML with a new "NEXT* method for forms, and a 
new <TOP> tag, which are designed to take advantage of the fact that client is fully able to save its own state and use 
this information in determining subsequent states. 

(vii) The "NEXT" Form Method 

45 

[0274] A form in an HTML page consists of one or more input elements for gathering data from the user. The data, 
each piece tagged with the name of the input element from which it came, is submitted to a server according to two 
parameters in the FORM tag: the METHOD and the ACTION. The ACTION is a URL to which the data are usually 
appended, while the METHOD is either GET or POST GET is used to fetch another page based on the data, while 
^ POST is usually used to send data to finalize a transaction. 

[0275] To these two methods, the present invention adds a new NEXT method. Generally, the NEXT method allows 
a form to be specified in multiple parts, with each part including a subset of all of the input fields of the overall form, 
and the data for the entire form stored in an external data structure. 
[0276] The NEXT method has the following effects: 

>5 

1 . The method used on the ACTION URL is "GET" without any modification of the URL; the page is simply fetched 
from the server. GetURL is the function called for the protocol handler 112. 

2. Any form in the fetched page begins with the name/value data-set active in the form on the current page. This 
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includes any name/value data that was passed from a previous page. This replaces the use of "hidden" input fields, 
avoiding the bandwidth penalty of having to transfer the data up to the server and have it transfer the data and the 
page back again. Instead, the page can reside on the server without an associated CGI script, or it can reside on 
the device, having been downloaded with the other pages that make up the transaction when the user subscribed 



[0277] Figs 1 8a-1 8b illustrate the HTMLp source and pages for a multi-part form that captures the same information 
as the illustrated conventional HTML pages, but presents in a significantly more useful and easy to use format for a 
screen display 136. The first three pages, "purchasefomn.html," "addr.html," and "credit, html" all use the NEXT method 

10 in the <FORM> tag to specify the next page to be loaded to obtain additional inputs. The last page "confirm.html," uses 
a conventional ACTION value to specify the CGI script for processing all of the data accumulated on the multi-part 
form. In this manner, much lower degree of bandwidth is needed between the server and the client to obtain all of the 
inputs to the form and transmit them back to the server, since the client (the wireless communication device 100) 
maintains the state data of the previous input pages. This state data of the name, address, credit card number, and 

IS so forth is maintained in an Internal data structure of the wireless communication device 100 in its memory 126. and 
thus need not be embedded in HIDDEN type input elements as in conventional HTML, This internal data structure is 
created as the first page is parsed by the HTMLp content handler 114c, and updated as each new page in the multi- 
page form is loaded. 

[0278] The <TOP> tag and "DONE" action used in the "confirm. html" page are explained in the following section. 

20 

(viii) Complex Interactions 

[0279] Given that what would be a multi-element form in standard HTML displayed in a desktop browser can now 
be transformed into multiple pages in HTMLp, each of which contains a one- or two-element form (in order to fit on the 
25 screen display 136 comfortably), a user might easily find herself in the middle of providing data for each of the fields 
and decide she wishes to terminate the whole process. If all she can do is go back to the previous page, this could be 
a slow and tedious process to terminate the transaction. 

[0280] To make termination of a multi-page form easier, the present invention allows a page to be marked as the 
beginning of a complex interaction a user might want to exit completely. It does this by providing the <TOP> tag: 
30 <TOP> at the desired location of the "top" of the interaction. Such an interaction may be a multi-part fonn. or any 

other complex group of pages. 

[0281] To access the top of an Interaction, a softkey 130 is defined using the <KEY> tag with an ACTION attribute 
of "DONE". When this softkey 130 is selected by the user, the user will return to the page that referred the user to the 
most recent page marked with <TOP>. This processing of the DONE value for ACTION takes place during the HTM- 
35 LpActtvate function, as descrbed above. 



[0282] The display of HTML on a conventional wireless communication device 1 00 is further hampered by the heavily- 
40 restricted keyboard and the absence of any pointing device. In a typical HTML environment, there is a scrollbar that 
can be clicked or dragged, a tab key to shift between fields in a form, and a mouse that can select hyperlinks included 
in the content should the user wish to follow them. 

[0283] In a wireless communication device 100 in which the present invention advantageously operates, however, 
there Is only the up key. down key. and possibly one of the softkeys 130 that may be relied upon to provide navigational 
45 controls. To provide a rich set of navigational abilities, the present invention provides the following features to HTMLp. 

(i) Form Entries 

[0284] When a page contains form elements, the Up and Down arrows are overbaded to allow moving between the 
50 form fields in the following fashion: 



If the next (for the Down arrow) or previous (for the Up arrow) field in the form is visible, then it is made the active 
form field. This is denoted by a graphical selection indicator; a text input element will also get a blinking text cursor 

If the next (or previous) field in the form is not visible on-screen^ the screen is scrolled so that the next (or previous) 
line of the page is brought on-screen. If the next (or previous) field is in the line that was brought on-screen, then 
it will be made the active form field. Otherwise, the current form field remains active. 
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(b) Navigation 
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[0285] As the screen display is scrolled, the current form field , is continually updated without requiring the user to 
directly select the field. In this manner, the user can easily switch among fields merely by scrolling, while being able 
to predictably read explanatory text leading up to the next field to be filled in. 

[0286] In addition to this, if the first softkey 130 is not bound by the page to some other purpose, it will change its 
action in the key binding table as the current form field changes, as follows: 



Table 1 : 



Softkey Navigation Defaults 


GADGET WITH FOCUS 


SOFTKEY 
LABEL 


ACTION 


Text field 


no label 




Scrolling List (single selectable) 


OK 


Selects and generates Submit 


Scrolling List (multi-seleciable) 


Select 


Selects/de-selects Item. 


Popdown (closed) 


Open 


Opens popdown 


Popdown (open) 


Select 


Closes popdown and makes selection 


Checkbox (selected) 


Clear 


De-selects 


Checkbox (unselected) 


Select 


Selects 


Radio button (unselected) 


Select 


Selects button 


Radio button (selected) 


no label 




Standard link 


Select 


Activates Link 


Phone:Dial link 


Call 


Goes to Dial screen displaying the number (can also be 
activated with Send button). 
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25 



30 



35 



40 



45 



50 
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[0287] The various actions defined In Table 1 provide for appropriate and dynamically variable behavior of the softkey 
1 30 depending on the type of user interface gadget that is the current fonn field. These actions are dynamically assigned 
as the user scrolls a page and changes the focus between gadgets, thereby changing the current form field. For ex- 
ample, if the current fomn field is a hyperlink, then the softkey Is automatlcany assigned to the URL for the link, and 
selection of the softkey automatically fetches the hyperlink. If the form field is some type of selection device, such as 
a list, popdown. checkbox, or radio button, then the softkey will either select, deselect, or submit an item from the 
selection device, as appropriate. For example, if a scrolling list has an item preselected using the SELECTED attribute 
(with or without the expression evaluation feature of the present invention) then the softkey 130 Is defined to deselect 
the item. 

[0288] This functionality for page navigation is implemented in the HTMLpProcessKey function. This function is called 
by the shell 106 when no other entity of the current page elects to receive an Input keystroke. The input to the function 
is a key number indicating the key of keypad 128, and a Boolean indicating whether the key is pressed or released. 
Referring to Fig. 15 there is shown a flowchart of one embodiment of the HTMLpProcessKey function. 
[0289] If there is a URL associated with the key, then the ProcessKey function 606 invokes 1 502 the GetURL function 
of the shell 106, passing the associated URL. The shell 106 will process this URL as illustrated in Fig. 6, to determine 
the appropriate protocol handler 112 and content handler 114 for handling the URL. 

[0290] The function determines 1502 from the key number whether or not the key has been bound to some action 
using the <KEY> tag, or the KEY attribute of the <A> or <INPUT> tags. If so, and the key is not a softkey 130 (which 
Is handled by the shell 106), then that action is passed 1504 to ShellActivate when the key is released. 
[0291] Otherwise, only the Up and Down keys are handled specially (1506); all others are passed 1508 to ShellDe- 
faultProcessKey to receive their default handling. 

[0292] The behavior of the Up and Down keys depends on whether there are selectable user interface gadgets on 
the page. A selectable gadget is either a form input field (from the INPUT, SELECT, TEXTAREA or OBJECT tags), or 
a hyperlink (if the LINKMENU tag is present). If there are no selectable gadgets on the page (1509), then the function 
makes 1514 the next line in the given direction visible. 

[0293] If there are selectable gadgets on the page (1509), the reaction to an UP or DOWN key is as follows. If the 
next user interface gadget in the chosen direction is visible (1510), the function makes 1516 tHat gadget the current 
gadget. If the next user interface gadget is not visible, then the content area 214 is scrolled 1512 so that the next line 
in the given direction is visible. If this makes the next gadget visible 1513, it is made 1516. the current gadget. If no 
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user interface gadgets are visible, then no gadget is cun'ent. 
(if) Content-as-Menu 

5 [0294] Content that does not contain a form can roughly be grouped into two classes: 1) informational content that 
is meant to be read, and 2) menu content that allows the user to select something from a list, in order to get further 
information or perfomn some action. 

[0295] The scrolling and link-selection behavior needed by the user is different for each of these types of content. 
In Infonnational content, the scrolling should allow the next piece of the text to be read (as that is the focus of the 
10 content), with any links being selected from a menu (the links are of secondary importance). For menu content, however, 
the importance is reversed: the text serves to explain the links, but it Is the links themselves the user needs to see. As 
such, a link should always be selected and any scrolling that occurs should occur in the context of getting to the next 
link. Conventional HTML does not distinguish between these types of content, and provides no mechanism for altering 
the navigational features of the computer displaying the content to accommodate their differences. 
IS [0296] To distinguish between these two types of content, and provide the desired navigational controls, the present 
invention provides a new <LINKMENU> tag. The <LINKMENU> tag can be given in the header to indicate the content 
is a menu of choices. The syntax is as follows: 

<LINKMENU TARGET=na/neNOSCROLL> 
[0297] The TARGET attribute has a value that is matched against the NAME attribute for all links on the page. The 

20 link whose name value matches the TARGET value is the link that is initially selected when the page is displayed. If 
the TARGET value takes the fomri of a URL (the first part of the value is alpha characters followed by a colon), the URL 
is fetched and the returned contents are compared against the NAME attributes for all links on the page. 
[0298] If the NOSCROLL attribute is present, it requests that the display not scroW to make the selected link visible. 
[0299] Specifying a <LINKMENU> has the following effects: First, links are not distinguished graphically (e.g. they 

25 are not underiined), as in conventional HTML. Second, the first link on the page is marked as selected (unless the 
TARGET attribute is given). Finally, the up and down keys set the current user interface gadget to the previous or next 
link that is visible, as described in the HTMLp Process Key method. The next link Is defined as the one below the current 
one and the shortest horizontal distance away; this allows columns of links to be handled gracefully and in an expected 
manner. If the previous or next link is not visible, the screen scrolls a single line in the appropriate direction. If the 

30 desired link is then visible, it is selected, otherwise the current link remains active, unless it is now not visible. 

[0300] lf<LINKMENU> Is nof given in a page, the content is treated as follows. First, links are distinguished by un- 
deriining them." Second, If the last softkey is not bound to anything, all links in the page are gathered into a menu 
bound to that softkey. Finally, the up and down selectors scroll the page one text line at a time. 
[0301] This functionality of the <LINKMENU> tag is effected by the HTMLp content handler 114c when the handler 

35 parses the page and sets up the key binding table and menus. 

[0302] Fig. 19 illustrates an example of the second type of behavior, where <LINKMENU> is not specified. In this 
example, all of the links to other content including files, such as iguana.gif, and lizards/blue-tongued-iguana.html, or 
database data, <a href=map?city=adelaide label=map>, are automatically placed in a menu named "Links" that is 
bound to the second softkey 130. This menu is displayed, as in the second image, when the softkey 130 is pressed. 

40 [0303] Fig. 20 illustrates the first type of behavior, where <LINKMENU> is specified. Note that the links in the page, 
e.g., <A HREF=flights/ua909.html>UA 909</A>, are not underiined, as in conventional HTML. Rather, the Up and 
Down arrows will move and select these links in order 

(iii) Binding a Link to a Key 

45 

[0304] The present invention provides new attributes for the <A> tag. These attributes provide a compatible way to 
provide content for both a wireless communication device 100 and a desktop computer, as a standard HTML browser 
will ignore the attributes. These attributes are the KEY and LABEL attributes: 
<A KEY=i^e/LABEL=string HREF=ur/> 
50 [0305] If specified, the KEY attribute asks that the indicated key should follow the URL specified by this for the HREF. 
The "back" key may not be bound in this way. This attribute thus provides a means for binding a specific key to a 
specific URL. 

[0306] If specified, the LABEL string will be used in one of two ways: 

[0307] If a KEY is also provided and is a softkey 130, the string will be the label for the softkey 130 displayed on the 
55 screen display 136. 

[0308] If a KEY is not provided, the string will be the label used in the menu of links that is automatically built by 
HTMLp content handler 1 14c when the LINKMENU tag is not given. In the absence of a LABEL attribute, the text of 
the link will be used (as much of it as will fit). 
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(iv) Binding Keys to Input Elements 

[0309] Conventional HTML provides for SUBMIT and RESET attributes for the <INPUT> tag. However, these at- 
tributes a hardcoded to either a return key, or a mouse click on a user interface gadget. 

5 [0310] The present invention extends the use of the SUBMIT and RESET input elements by enabling them to also 
be bound to particular keys, using a KEY attribute for the <INPUT> tag that specifics the desired key to be bound. 
[0311] In a preferred embodiment, by default, SUBMIT elements are bound to a second softkey 130, and RESET 
elements are bound to the third softkey 130. If a device has only two softkeys 130, RESET elements are inaccessible. 
Given the simplicity of fonns on these devices, however, this is not usually a problem. 

10 [0312] A form with multiple SUBMIT elements will have all of them placed in a menu on the second softkey 130, 
unless an explicit key binding is given. Multiple SUBMIT or RESET elements bound to the same key will be combined 
Into a menu on that key. 

(c) Specialized Content 

75 

[0313] The present invention also includes additional extensions to HTML to support specialized types of content or 
provide a way to map existing World-Wide Web practices to the smaller screen display 136 of the wireless communi- 
cation devices 100. 

20 (i) Dialing the phone 

[0314] Like other telephone type products, wireless communication devices 100 can access DTMF-based network 
services, or other systems that use DTMF tones to control functionality, such as voicemail systems, and the like. Ac- 
cordingly, HTMLp includes a new tag that makes it very easy to generate DTMF tones when a page Is fetched in order 

25 to easily interface with such systems. This is accomplished using the new <DIAL> tag: 
<DIAL NA^E=string /COA/-nty/77i>er NO SCREEN CHAN GE>(nln@ f;)+</D I AL> 
[0315] n is a number or special dial code (like p for pause). @t; specifies a duration, in tenths of seconds, if it is 
present. The choice between generating DTMF tones and making a new call is made based on whether a call is 
currently active (not on hold): if a call is active, the DTMF tones are generated. 

30 [0316] The NAME and ICON attributes specify the party being called, to be used in the page that is displayed while 
the call is being placed, and in the follow-up page that allows the dialed number to easily be placed in the phone book. 
While the ICON attribute is also used in a call-connecting page, its primary purpose is in a call follow-up page that 
allows the user to store the dialed number in the phone book: phone numbers are identified by their icon in the embedded 
phone book object and elsewhere, and the ICON attribute specifies the icon to use, if the user does not change it when 

35 actually entering the number. 

[0317] The NOSCREENCHANGE attribute indicates that the display should return to this page after the call is suc- 
cesstul, rather than changing to be a standard call management page, such as in Fig. 22. 

[0318] Any attempt by a non-privileged page to actually make a new call is confirmed with the user, to prevent ma- 
licious content from issuing unwanted phone calls. 

to [0319] This tag allows for a user interface page to provide a graphical Instruction sheet for existing DTMF-based 
command trees. The user activates functions on the screen which then bring up a new page that generates the ap- 
propriate DTMF tones to execute the action the user requested, and that displays the operations available to the user 
in the new state. Fig. 25 Illustrates an example of this type of use. The file entitled "Voice Box" is a user interface page 
for accessing a voice mail system. The <DIAL> tag in line 2 includes the telephone number for the voice mail system, 

f5 and a user password "4416722". Lines 4-8 define the keysof the keypad 128 to activate various functions of the system. 
In the file entitled "Listen", the <DIAL> tag in line 2 first generates the DTMF tone corresponding to the number "5" 
which triggers the voice mail system to enter a playback mode. Lines 4-8 here assign respective number keys 134 to 
various actions, each of which is a URL to dial a specific number that generates further functions of the voice mail 
system. Thus, using the <DIAL> tag allows the user to navigate a voice response system's command tree in graphical 

'*o manner, while providing the correct underlying DTMF signals. 

[0320] The <DIAL> is provided by the HTMLp content handler 114c to the shell 106, which in turn provides it to the 
telephone protocol handler 112g for processing, and generation of the DTMF tones corresponding the numbers pro- 
vided in the URL. 

'5 (ii) Advertising Content 

[0321] Existing World-Wide Web content is largely supported by graphical advertising banners. The limited bandwidth 
and screen size of the screen display 136 on wireless communication devices 100 makes this sort of advertising 
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problematic, however since conventional image-intensive advertising banners will not properly display on a wireless 
communication device 100. 

[0322] The present invention overcomes this limitation by providing an extension to the existing <MARQUEE> tag. 
This tag normally specifies text to be scrolled across the screen, but is limited to the <BODY> section of the page. 
Conventionally, if the <MARQUEE> tag is placed in the <HEAD> section, a conventional browser will ignore tag. 
[0323] In the present invention. HTMLp content handler 114c allows the <MARQUEE> tag to be placed in the 
<HEAD> section of a document. When so used, the accompanying advertising text in the <MARQUEE> tag alternates 
with the title of the page and any delayed help that has been specified with the <HELP> tag. This functionality is 
implemented by the HTMLp content handler 1 1 4c responding to a call from the shell 106, which is asked to notify the 
HTMLp content handler 1 14c every other time the shell 106 would otherwise display delayed help. When notified, the 
HTMLp content handler 114c instructs the shell 106 to scroll the advertising text across the title area 210. 
[0324] In summary, the HTMLp content handler 114c and the HTMLp extensions provide numerous beneficial tea- 
tures and functions not present in conventional HTML. 

b) The Advertising Manager 

[0325] The advertising manager content handler 114a selects an advertisement to display at idle time, deletes old 
advertisements or those that have been responded to or run their requisite number of times. The advertisements are 
defined as HTML or HTMLp pages and stored in memory 126 as part of the user interface definition files 104. Adver- 
tisements are typically downloaded to the wireless communication device 100 by the operator on a scheduled basis. 
After the user responds to them, or they have been displayed a certain number of times, or if a more-important adver- 
tisement arrives, downloaded advertisements are automatically deleted. 

[0326] The advertising manager content handler 114a implements the basic content handler functions as follows: 

(1) AdvertOpen 

[0327] An advertisement page is never rerun, as the advertising manager content handler 1 14a marks the page as 
temporary, and thus does not store it on the URL history stack 108. This means that any other page that comes up (e. 
g. incoming call, battery low, or like) will replace the advertising page in the URL history stack 108. 
[0328] When AdvertOpen is called, it looks at the set of advertisement pages it has available and chooses one to 
display. It opens the file and passes the stream to the HTMLp content handler 1 14c to display. 

(2) AdvertClose 

[0329] This function checks the advertisement page it was displaying, and if it is marked for deletion (because it has 
been responded to or because it has been displayed the required number of times), it deletes the advertisement page. 

(3) AdvertActlvate 

[0330] The string is passed to the HTMLp content handler 114c to be processed in HTMLpActivate after the current 
advertisement is marked for deletion since the user has responded to it. 

(4) AdvertProcessKey 

[0331] Any key press that is not otherwise bound in the advertisement page causes the page to be closed and the 
key press to be reprocessed by the page that was active before the advertisement page appeared. 

c) The Call Manager 

[0332] The call manager content handler 1 1 4b is used for two purposes: 

1, To display the active calls 

2. To display the connection progress for an outgoing call 

[0333] There is only ever one pjage on the URL history stack 1 08 that currently uses the call manager content handler 
1 14b, and that page is in one of these two modes. The call manager content handler 1 14b implements the basic content 
handler functions as follows: 
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(1) CallManagerOpen 

[0334] If the page is being rerun, this function makes the window It created before to display the page visible again 
and redisplays Its contents. 

[0335] If this is the first time the page is being opened, CallManagerOpen examines the stream of data for the URL 
to see if there is a phone number to be dialed. In the stream will be a string of the form: 

num=string& name=string&\con=n 
[0336] This tells the function the number to dial (with following DTMF tones, if any), the name to display for the 
number (if the number itself is not in the phone book), and the icon to display along with the name. 
[0337] If there is a number to dial, the call manager content handler 114b will enter dialing mode, using an interface 
provided by the telephone control module 120 and display a dialing page showing the progress in making the phone 
call. This page provides feedback as to which DTMF tones are being dialed, and will report errors should they arise. 
Figs. 21a-e illustrate an example dialing page, showing the status of the connection as "connecting," "line is busy," 
and so forth. In Figs. 20c-e also show the entire phone number being dialed, with a moving indicator under the present 
digit which is being dialed. 

[0338] In the absence of a number to dial, the content handler 114b CallManagerOpen function displays the list of 
active calls, along with interface to manipulate them. A simpler interface is presented if there Is only one call active. 
Figs. 21 a-c illustrate these Interfaces. Fig. 21 a shows the interface for a single active call; Fig. 21 b shows the interface 
for multiple active calls; Fig. 21c shows the same interface as Fig. 21b but with a softkey 130 menu that allows for 
selection of whether to conference or hold a call. 

(2) CallManagerClose 

[0339] If the page is being closed pemnanently, and is removed from the URL history stack 108, this will free up the 
resources it allocated to display the active calls. If there are still calls active, this function calls ShellAddldleHook so 
after a certain amount of time with no user input, the list of active calls will again be displayed. 

(3) CallManagerActivate 

[0340] This function looks for the following commands that are bound to the softkeys 130, depending on what actions 
are available for the selected call: 

Conference Joins the other (on-hold) call to the current call in a multi-party call. 
Split Removes the selected call from the multi-party call it is in. 

Hold Places the selected call or multi-party call on hold. 

Pick Up Activates an on>hold call or multi-party call. 
Back Closes the call manager screen. 

Stop Stops the current DTMF sequence and displays the list of active calls in place of the call-in-progress 



(4) CallManagerProcessKey 

[0341] This function handles the Up and Down keys in the multiple-call case, moving the user selection from one 
call to the next. The call that is selected is made the active call and the old active call is put on hold. 
[0342] Number keys 134 generate DTMF tones if the active call is selected (in spite of the response to the Up and 
Down keys, which would seem to indicate that it is not possible to have the currently selected call not be active, it is 
possible for the selected call to be on-hoid if the user just asked to put it on hold and has not changed the selection), 
else a dialer screen is brought up, and the digit is entered as the first of a number to call. 

[0343] The End key terminates the current call. If the call is part of a multi-party call, it is removed from the conference 
before it is terminated. 

[0344] The Send key brings up the dialer screen, but does not affect the current call until the user hits Send to make 
the second call. 



screen. 
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d) The Main Content Handler 

[0345] The main content handier 11 4d serves largely as a front-end for the HTMLp content handler 114c to display 
the main page of the device. 

5 

(1) MainOpen 

[0346] Resets the input mode to numeric and the shift state to unshifted, so when the user starts pressing keys, they 
start dialing a number. 

10 [0347] It then opens astreamtothemain page, and passes the stream to the HTMLp content handler 11 4c to display. 
A sample main page is illustrated in Fig. 22. 

(2) MainClose 

15 [0348] Calls HTMLpClose with the same arguments. 

(3) MainActivate 

[0349] Calls HTMLpActivate with the same arguments. 

20 

(4) MainProcessKey 

[0350] If the key is End and there are calls active, this function will bring up the active call screen, so the user does 
not have to wait for it to appear to be able to hang up. 
^5 [0351] Any other key press is passed to HTMLpProcessKey to be processed. 

7. The Protocol Handlers 

[0352] In accordance with the present invention, the functionality of the wireless communication device 100 is ac- 
30 cessed through a number of protocols and protocol handlers 1 12 that fetch or post data or execute a requested function 
in response to a URL identifying such data or function. , 

[0353] In a preferred embodiment, there are three rnain protocols for interacting with the wireless communication 
device 100: phone, message, and config. A fourth protocol, the "extra" protocol, enables HTMLp template pages to be 
used for most of the user interface, as described with the <TEMPLATE> tag and other features. 
35 [0354] For each protocol, the supported URLs are separated into those that return an object to be embedded in an 
HTML or HTMLp page, and those that display content or activate a function of the wireless communication device 100. 

a) The phone Protocol 

40 [0355] This is the primary protocol for accessing the features of the device and the various embedded objects that 
are written in C, rather than HTML. It is decoded by the telephone protocol handler 112g. These embedded objects 
include the phone book object, recent call list object, and the like, as described above. Each embedded object has 
parameters width and height. These parameters are specified in the URL for the embedded object, and define the pixel 
width and height for a window to be provided by the embedded object to display its output. 

45 [0356] Each embedded object also has a set of methods which It executes according to the URL specification. 

(1 ) Embedded Objects 

[0357] For each embedded object, there is described the parameters it accepts, as well as the methods that can be 
50 perfomned on it. These methods are strings that are bound to keys 128, hyperlinks, or softkey menu entries, 
phone :dia ling ? widt h=nt/mbe/& h eig h t= n t/znter&sto rekey = n,storelabel/editlabBi 

[0358] Returns a stream containing an embedded object for dialing the phone. The object can look up entries in a 
stored phone book data structure by number or by name, and displays matches below Its input field, as described 
above, with respect to the phonename and phonenum attributes of the <INPUT> tag. 

55 
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Parameters 



[0359] 



5 storekey Specifies which softkey 130 should be used to allow the user to edit an entry, if she has selected an entry 
In the match list, or to store the number or name that she has entered. The storelabel and editlabe/ \/a\ues 
specified for the storekey parameter specify the label to be given to the softkey when it is set to perform 
either of those two functions. 



10 Methods 



[0360] 

edit Requests that the number selected in the match list be edited. 

15 

store Requests that what the user has typed be stored In the phone book by entering the new-phone book-entry 
sequence with the appropriate field filled in from what the user has typed. If the current text entry mode Is 
numeric, the entered data are taken to be the phone number; If the current text entry mode Is non-numeric, it 
Is taken to be the name. 

20 

[0361] Any action that contains an '@* character is also considered a method of this object. The @ escapes described 
for the phone:list object will also function here. 

phone: Iist?width=n(//37i7er£ be\ghi=znumber&od\tkey=nJabei& serv\ce=string& data=sfrm^£show status 
[0362] Returns a stream containing the phone book embedded object to display records from the phone book data 
25 structure. 



Parameters 



30 



[0363] 
editkey 



Specifies a softkey 130 whose label and action should be changed depending on what is selected 
(only phone numbers can be edited). 



35 



service, data Specify strings to display In the status message area 212 when a service (URL) or data (stored 
content) entry is selected, while showstatus determines whether any status message 212 is dis- 
played (for phone number entries, the phone number is displayed). 



Methods 
io [0364] 

new If the list is in search mode and an entry in the match list has been selected, a new-phone book-entry se- 
quence, a sequence of user Interface definition files 104 that collect the name, number, and so forth, and 
store the result in the phone book, is entered using the name of the selected entry as the name for the new 
>5 entry. If no entry in the match list is selected, the new-phone book-entry sequence is entered with what the 

user has typed as initial data. The data are used for the phone number if the current text-entry mode is 
numeric, or for the name if the current text-entry mode is not numeric. 

edit A URL is generated to edit the current phone book entry, and the URL is fetched. 

iO 

delete The current phone book entry Is deleted, after confirming the request with the user: 

[0365] Any URL that contains an @ character is also considered a method of this object, and is searched for the 
following escapes. If an escape is found, it is replaced by the relevant piece of data from the current selection. Once 
■5 all escapes hiave been substituted for, the resulting URL is fetched. 
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# 



Table 2: 



Escapes Values 


Escape 


Replaced By 


@\ 


The record ID of the selected entry 


@o 


The offset of the selected phone number in the entry (0-7) 


@n 


The name in the selected entry 


@N 


The selected phone number (generates an error if the selected Icon is not a phone number) 


@\ 


The icon of the selected phone number (generates an error if the selected icon is not a phone number) 


@S 


The speed dial number of the selected phone number (generates an error if the selected icon is not a 
phone number) 


@r 


The ring tone for all numbers in the selected entry 


@R 


The ring priority for all numbers in the selected entry 


@c 


The category for the selected entry 


@g 


The group within the category for the selected entry 


@@ 


A single character. 



phone:recentcall?filtei^num6eri^rtkey=n^ed/f/abe//sfore/a6e/&callkey=n,/ai>e/&^ 
25 ht=n&noempty 

[0366] Returns a stream that contains an embedded object that can display the list of recently-received or -placed 
phone calls. Each item in the list of calls has a set of flags associated with it. The object can be told to display only 
items that have a certain flag set. The one flag currently defined is bit 0, which marks a call from a number where the 
user failed to answer the call. 

30 

Parameters 

[0367] If filter \s present, It indicates only calls of a particular type should be displayed (the sole current filter value 
is 1, meaning incoming calls that went unanswered), editkey and ca///cey specify a softkey whose label and action 
35 should be changed based on the call that has been selected. If noempty is present, It Indicates that the screen containing 
the object should not be displayed if the list of calls, after filtering, is empty. 

Methods 

40 [0368] 

edit If the current selection is a number that is in the phone book, this brings up the phone book edit screen for 

the number 

^5 store If the current selection is not a number that is in the phone book, this brings up the new-phone book-entry 
sequence with the phone number set to the current selection. 

call Initiates a call to the number in the current selection. 

so dismiss Closes the screen after clearing the "missed" flag (bit 0) for all items in the list. 

p h o ne : ri n gto ne? widt h= /iumber& h e i g ht= nt//n6er&pt r Add r= hex 

[0369] Returns a stream that contains an embedded object that can display the list of ring tones the device can 
produce for an incoming call. 

55 

Parameters 

[0370] If ptrAddr \& given, the object gives the user the option of using the system-default ring. When the user has 
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chosen a ring, its number is then placed at the memory address given by hex. If ptrAddr 'is not given, the object sets 
the system-default ring. 

Methods 

5 

[0371] 

test Plays the selected ring tone through once. 

10 ok Sets the ring tone to that selected and closes the screen. 

phone:speeddial?wtdth=num6er&height=nu/n6er&ptrAddr=/}exnc//nber&Name=sfr/ng&icon= 
[0372] Returns a stream containing an embedded object to display the list of speed dial locations. 

IS Parameters 

[0373] prr/\c/c/r specif ies where the object should store the selected speed dial number when the user chooses an 
entry. The Name and icon arguments are identical to those In phonerstore, specifying the name and icon of the number 
being assigned a speed dial number. 

20 

Methods 
[0374] 

^5 ok Sets the speed dial numberto the current selection, if the current selection is not currently assigned to.another 
number, then closes the screen. The Name and icon arguments are used in building a confirmation screen 
for the user. 

clear Clears the assignment of the selected speed dial entry. 
30 (2) Content/Command URLs 
[0375] phone: active 

[0376] Returns a stream of type "CallManager" that causes the active-call screen to display, allowing the user to 
manipulate any calls that may be active. Does nothing if no calls are active. 
35 phoneranswer 

[0377] Causes any Incoming phone call to be answered, returning a stream that causes the active-call screen to 
display. Does nothing if no incoming phone call. The referring URL is popped from the URL stack if there was an 
incoming phone call. 
phoneieonf 

*o [0378] Causes any incoming phone call to be answered and joined with the current active phone call. Returns a 
stream that causes the active-call screen to display. Does nothing if no incoming phone call. The referring URL is 
popped from the URL history stack 108 if there was an incoming phone call. 
phone:dial?num=:s(r/np£name=sfr/ng&icon=nuin/>er&hidden 

[0379] Causes a voice call to be created to the indicated number If name and icon are provided, they are used in 
fs the page that displays the call progress, and in any follow-up page where the user is asked if she wishes to add the 

number to the phone book. If hidden is specified, the user will not see the call once it has connected (the active call 

screen will not be displayed). The URL returns a stream that causes the call-progress screen to be displayed. 

[0380] If no arguments are given, the URL returns a stream that causes a dialer screen to be displayed, allowing the 

user to enter a phone number to call. 
» [0381] If the page issuing the request lacks sufficient privilege, the user will be asked if it is permissible to dial the 

phone number. For example, a received text message lacks sufficient privilege, as it might contain a call to a 900 or 

long-distance number that the user is not aware of. 

phone:display?id=nu/nber 

[0382] Returns a stream that displays the Data field of the specified phone book record. 
•5 phone:edit?name=sfr//7p4inum=sfr/npAoffset=numberA td=number 

[0383] Returns a stream that causes a new/edit screen of the phone book to be displayed with the passed parameters. 
Offset and id are used only internally to edit an existing record (offset indicates which phone number to edit, while id 
is the identifier of the record to edit). Name and num, however, can be used to create a new phone book record, giving 



39 



r.<EP 



.1152332A2_L> 



EP1 152 332 A2 

the user a chance to select an appropriate icon and otherwise edit the entry before storing it in the phone book. 
phone:firstopen?password=:s^r/n£r 

[0384] Checks the given password string against that stored in the configuration settings. If it matches, the referring 
screen is popped and replaced by phoneinnain. If It does not match, the phone is turned off. This allows the power-on 
5 security screen to be an HTML page, 
phoneiignore 

[0385] Causes any incoming phone call to be rejected. The referring URL is popped from the URL history stack 108 
If there was an incoming phone call. Does nothing if there is no incoming call. No stream is returned, so the URL that 
was active before the referring URL was fetched Is redisplayed. 

10 phone:tndir?url=str/ny^ popz=action 

[0386] Fetches one or more URLs (which activates their side-effects, whatever they may be) before retuming the 
stream from the last one fetched. If the pop argument Is given, it indicates that one or more URLs should be removed 
from the URL history stack 108 before the returned data are displayed, action can be one of pop, abort, or clear, to 
remove one URL, all the URLs in the current interaction, or all URLs from the history stack 108. 

15 phOT\e:\ook7cat=number& sorX&form=format 

[0387] Retrieves names from the phone book that are in the category whose number is given by the cat argument. 
If the sort argument is given, the results are sorted alphabetically. The form argument specifies In what format the data 
are to be provided. They are always in some form of HTML (the result of this URL is an HTML stream), but the tags 
used vary as follows: 

20 

• link: each entry name Is formatted as a link to the appropriate place: for an entry with a Service field, the HREF 
is the contents of the Service field, while for an entry with a Data field, the HREF will show that data. All other 
entries dial the first number in the entry. 

• form: the names are formatted as <OPTION> elements of a <SELECT> list (which must surround the <INC> tag 
25 that fetches this data). The value of each option is the URL, as described for link. 

• menu: each entry is provided as a <KEYMENU> tag in the same manner as for link. The key to use is specified 
by form=menu=x, where x is the key. 

• count: produces the number of records that are in the given category. 

30 [0388] The phone:look URL, when combined with the new <INC> tag, allows an HTML page to display a subset of 
the phone book in some sort of branded, graphical context. More importantly, it provides a simple way for both a service 
operator and for the user to manage which services are available to the user. Groups of services are stored in the 
phone book with a particular category. The device then has a page that uses this URL to display those entries and 
allow the user to select one of the services. Adding and removing services are simply a matter of adding or removing 

35 an entry in the phone book; there is no need to modify the page that displays the list of sen/ices. 
phoneimain 

[0389] Returns a stream that causes a predefined main screen to be displayed, 
ph o ne : release? id=:/7u/n/7er 

[0390] Releases the active call, or the specified call if the id argument is given. Returns no data. 
40 phone:shortcut?num=n 

[0391] Activates a shortcut function, n ranges from 0-9. 

[0392] Shortcuts are defined by the manufacturer of the wireless communication device 100, and are typically acti- 
vated by holding down one of the softkeys 130 and then pressing one of the numeric keys 134. They are generally 
available from all screens, with the exception of the power-on password screen. 

45 [0393] For example, shortcut 1 might-lock or unlock the keypad, while shortcut 2 might mute the phone's ringer and 
shortcut 3 might activate or disable password protection when the wireless communication device 100 is turned on. 
Certain shortcuts might also be restricted on certain screens other than the power-on password screen, 
phone: sto re? N ame=stnngS P ho n e=speec^ tcon=^string&Ovin e r= strings Se rvice= t/r/4ftCa tego* 

ry= nurrtber&Gk roup=number8tRlng=number8LDeda=type ^acfa£a&speed=speec/& ico n= iconit id=/dS&ofr- 

so set =number&pna^nSipop=string 

[0394] CreateS: augments or edits a record in the phone book. If id and offset are specified, the selected phone 
number In that record is edited. Otherwise, if a record with the same Name already exists, the record is augmented, 
while an unmatched Name causes a new record to be created. 

55 
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Parameters 



[0395] 
s Phone 



10 



15 



20 



25 



30 



15 



to 



Owner 
Service 

Category 

Ring 

Data 



Pop 



The contents of this parameter vary depending on whether the "speed" and "icon" parameters are spec- 
ified. 

If they are not specified, this parameter contains a string of the form " speed=icon=number/ 
speed=icon=number/.." In other words, a string that specifies one or more phone numbers, giving the 
speed dial location and Icon to associate with each. 

If "speed" and "icon" are specified, this parameter contains only the single phone number to store in the 
phone book. 

Specifies a password that allows the contents of the en*ry to be updated over the air. 

Specifies a URL to be stored in the entry. This URL appears like a phone number In the phone book, but 
when the Send key is pressed, the data for the URL are fetched. 

Allows an entry to be hidden from the nomnal phone book screen, but found by the phone: look URL for 
inclusion in an HTML page. Categories 0, 1, and 2 are displayed by the normal phone book. 

Specifies a ring tone (0 to 127, with 0 meaning to use the system default) to use when a call arrives from 
any number in this phone book record. If the high bit (32768) is set, it indicates that calls coming from any 
number in this phone book record should ring through, even If the device is in quiet mode. The high bit 
can also be set using the prio argument. If this is 1, the high bit will be set. 

Allows arbitrary data to be stored in a phone book record. The data appear like a phone number in the 
phone book, but when the Send key is pressed, the data are displayed. The first part of the argument 
value is the type of data. Typically this will be either text or HTMLp. The second part is the data itself, as 
a string of hex digits, two per octet to be stored. 

(Optional) Causes the URL that requested the phone:store URL to be removed from the URL history stack 
1 08 according.to the string value (pop => just the U RL is removed, done all URLs back beyond the most 
recent top URL are removed, and clears all URLs back to the main screen are removed). 



[0396] This particular command provides significant flexibility to the user. First, the DATA argument allows any data, 
not just telephone numbers, to be stored in the phone book. In particular, URLs, images, audio data, and any other 
content may be stored, creating a general purpose database in the wireless communication device 100. For example, 
a user may be viewing Web content, select a URL that is displayed, and immediately store it to the phone book for 
later recall. 

[0397] Second, the RING argument allows different ring tones to be specified for each phone book entry . This RING 
tone will be used when an incoming call is received from any number in that phone book entry. This allows the user to 
specify particular, distinct ring tones for various telephone numbers. For example, the user may specify particular ring 
tones for different family members, co-workers, a doctor's office or the like. 

[0398] Third, the RING argument also allows for priority ringing for any phone book entryand its ring tone, by setting 
the high bit of the ring tone value, or specifying a non-zero PRIO argument. A conventional wireless communication 
device typically includes a quiet mode that silences the telephone and normally prevents it from ringing for any incoming 
call. With the present invention, this RING argument can specify that calls from the phone book entry are not so blocked, 
and allowed to ring. Thus, the user may set this priority ringing for family members and other important persons, so 
that even during quiet mode, telephone calls from such persons are allowed to ring. 

[0399] The call manager content handler 1 14b implements this feature by comparing the telephone number of each 
incoming telephone call with Its store telephone numbers, and using the specified ring tone (if any) to select and control 
the ringing of the phone. 

b) The message Protocol 

[0400] Text messages, similar to alpha-numeric pages, can be received and viewed using the present invention. 
Messages are stored in a file and identified by a unique identifier. This protocol is handled by the message protocol 
handler 112f. 
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(1) Embedded Objects 



[0401 ] message: iist?width=n£//n6eri^height=nu/n/7er£type= type&num=string&\ockkey=nJockiabel/unio ck- 
label 

[0402] Returns a stream containing an embedded object that displays a list of the messages of the given type. 
Parameters 



[0403] 
num 



(Optional) Indicates that only messages from the given source are to be displayed. 



lock key (Optional) Specifies which softkey 130 is to be updated based on whether the selected message is currently 
locked; pressing that softkey will toggle the locked state of the message. The locklabei and unlocktabel 
portions of the parameter specify the label to be given to the softkey 130 based on the function It is then 
performing. 



type 



Methods 



(Optional) Specifies what type of messages are to be displayed. Possible values are "TEXT"» "FAX" or 
"VOICE". 



25 



30 



35 



40 



45 



50 



[0404] 

lock Locks the selected message against automatic deletion, 
unlock Unlocks the selected message, allowing it to be automatically deleted, 
new Begins composing a new outgoing message, 
.open Displays the selected message and marks it as read. 

[0405] Any URL that contains an @ is also considered a method for this object. It is searched for the following 
escapes; if an escape is found, it is replaced by the relevant piece of data from the current selection. Once all escapes 
have been substituted for, the resulting URL is fetched. 



Table 3: 


Escapes for Messages 


Escape 


Replaced By 


@i 


The record ID of the selected message 


@b 


The body of the selected message (URL-encoded) 


@n 


The phone number to call if one wishes to reply to the message by voice. For a numeric page (a message 
with just a phone number in it), this will be the number in the page. For all other messages, this is the 
phone number of the message sender. 


@s 


The phone number of the message sender 


@@ 


A single character 



(2) Content/Command URLs 



[0406] message: CO unt?type=lype 

[0407] Returns a stream that contains the number of messages that are waiting, as text. The possible type values 
are VOICE, TEXT, or FAX. Usually this is used with the <INC> tag in implementing an inbox for all types of messages, 
providing a list of the types of messages the device supports, where the list enables the user to get to the individual 
screen for that type of message. The list can use this URL and the <INC> tag to display the number of messages 
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available on this screen as part of the text that makes up the list. The URL can also be used in the TEST attribute of 
an IF tag to select a different <IMG> tag based on whetherthere are any messages of that type available. For example, 
a static Image could be used when there are no messages, while an animated one is used when there are messages 
of that type available. 
s message : o perate?rep ly=&delete= i&lock=& u n lock= &adj ust=:& i d= number 

[0408] Performs an operation on the message whose id is specified. The possible operations (only one of which may 
be specified in the URL) are: 

• reply: causes the message-composition screen to be brought up, with the destination address set to the sender 
10 of the message whose id Is specified. 

• delete: causes the message to be deleted. 

• delconfirm: causes the message to be deleted after the user has been asked to confirm the deletion. 

• lock: causes the message to be marked locked, which prevents It from automatically being deleted when the 
message store Is full. 

*5 • unlock: causes the message to be marked unlocked, which allows it to be automatically deleted when the message 
store Is full. 

[0409] If the atf/asf argument is given, it causes the URL history stack 108 to be adjusted in the following manner: 

20 • reply: no adjustment is made. 

• delete: the referring URL Is popped from the URL stack 

• lock, unlock: a stream from the message:read URL is returned for the message, replacing the referring URL. 

This URL requires sufficient privilege to operate. If the referring URL lacks the privilege, the operation is con- 
firmed with the user. 

25 

message:read?id=nu/77der 

[0410] Returns a stream to display the message whose id is passed. The stream is for a template HTML file. The 
parameters that fill in that template are retumed based on the contents of the message. 
message:send?addr=sfr/n£r&body=sfr/n^&newaddr=&newbody=&pop=&reply=:/d 
30 [0411] Requests that a text message be sent to the indicated address. If addr is missing, or newaddr is present, this 
returns a stream and parameters that allow the user to set the address for the message, while maintaining any body 
that was given. 

[0412] If body is missing, or newbody is present, this returns a stream and parameters that allow the user to add or 
edit a body for the message, while maintaining any addr and reply that were given. 
35 [0413] If both addrand body are given, and both newaddr and newbody are absent, the message is sent. If reply is 
given, the corresponding message is marked as having been replied to. 

[0414] If the message Is sent, and pop is present, the referring URL is popped from the URL history stack 108. 
[0415] This URL also operates with the POST operation (PutURL), where the addr is specified in the URL and the 
stream of data to put to the URL are taken to be the body of the message. 
to [0416] This URL requires sufficient privilege to operate. If the referring URL lacks the privilege, the operation is 
confirmed with the user. 

c) The confiq Protocol 

'5 [0417] The third protocol for interaction with device functions is the config protocol, which is used to set and get 
device configuration information. This protocol is handled by the config protocol handler 112b. 

[0418] The URLs that are formed with this protocol are the device settings themselves. When a URL is fetched, the 
current setting of the URL is converted to text and returned as a stream. When data are posted to a config protocol 
URL. the data are converted as necessary and the device setting is set. A config URL may address bits within a device 
'O setting, both for getting and setting. The URL then looks like this: 
config: setting. bitnumber:bitsize 
[0419] If '.bitsize is not present, 1 is assumed. 

[0420] Bftnumber runs from 0 to 31 , with 31 being the most-signifrcant bit. 

[0421] Most settings may be fetched by any module, though some (like the wireless communication device's PIN 
5 number) may only be obtained by pages with sufficient privilege (typically HTML files that are in the ROM memory 
126). No device setting may be set without sufficient privilege (again, typically by HTML files that are In the ROM 
memory 126). 

[0422] Multiple settings can be set by posting to "config:set". The stream then contains lines of the form "setting. 
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bitnumberbitsizelvalue " 



Table 4: 



5 


Configuration URLs 




URL 


TYPE 


FUNCTION 




config:keypadlock 


Boolean 


Engages or disengages keypad lock, when set. 


10 


configismspriority 


int16 


Rates how Important incoming messages are: 0 => display all messages, 1 => 
display messages with the smskeyword, 2 put all messages in the Inbox 




configrsms keyword 


char[16J 


Specifies a word to look for in incoming messages to determine if they are 
important enough to display. 




configiringtone 


int16 


Specifies a ring sequence (1 -127) to use by default. 


15 


confiq:ringmode 


int16 


Specifies how to ring the phore: 0 periodic ringing, 1 periodic ringing + 
vibration, 2 => ring only once, 3 do not ring at all. 




configrsetquietmode 


boolean 


When set, only calls from high-priority numbers will cause the phone to ring in 

Its normal way. 


20 


config:quietmode 


int16 


Specifies how to ring the phone for non-high priority numbers when in quiet 
mode. 0 => vibrate, 1=> chirp, 2 ^ dont do anything. 




confjg:setpassword 


boolean 


When set, causes the user to be asked for a password whenever the phone is 
powered on. 


25 


config:password 


char[4] 


The password that must be entered. 




confjgibacklight 


boolean 


If true, then backlight is turned on when the phone Is in-use. 




config:keyclk:ks 


boolean 


If true, then keystrokes generate a clicking sound appropriate to the key that 

was hit. 


30 


configrautosearch 


boolean 


If true, the phone book is searched for matches as the user dials the phone. 




config:followup 


boolean 


If true, and a call is made to or received from a number that is not in the phone 
book and that hasn't been called recently, the user is asked whether to put the 
number in the phone book. 


35 


config:lasttjme 


int16 


The number of seconds the last call was connected. 




config:totaltime 


int32 


The total number of seconds that spent connected. 



d) The "extra" Protocol 



[0423] The "extra" protocol is used primarily with the new <INC>, <IF> and <TEMPLATE> tags to enable HTMLp 
templates to function as the bulk of the user interface of the present invention. This protocol Is handled by the extra 
protocol handler 112c. 

[0424] Generally, extra parameters are passed to an HTMLp template cither from: 

1) the C code of the MM 1 102. 

2) as an argumenfs string to a file URL. This . lakes the form **Ti\e://fiienanie?variabiename=extra_datar, The extra 
data is stored with its variable name and used to complete the HTML for whatever page is fetching filename. 

3) as data from a previous form that used the new METHOD=N EXT attribute to pass the fomn data to the next URL. 

[0425] In addition, when a URL that is in an HTMLp page is fetched and it has no arguments, any parameters that 
were passed to the page that contains the URL being fetched are also passed to the URL that is being fetched. 
[0426] The extra protocol handier 112c looks for an argument that matches the URL and converts the argument to 
a stream. For example, "<INC src=extra:body>" will include the "body" argument into the HTMLp stream. As another 
example, assume there is an HTMLp page that is used to display a message in a standard format with standard 
graphical elements. The message to display is given as an argument for the URL that loads the HTML page. 
[0427] For example the URL 

"flleV/message.html?message=Please+enter+a+vaiid+phone-i-number" when given to the extra protocol handler 
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112 will stores the text "Please enter a valid phone number" as a text string with variable name "message." This extra 
data will be displayed in any other page by use of the "extra:message" URL, which will output the string data. Fig. 22 
illustrates this use. In this example, the extra data is retrieved by use of the <INC> tag., and results in the text string 
being directly Incorporated into the page. 

[0428] Generally, the extra protocol handler 112c is invoked as a result of the HTMLp content handler 1 14c parsing 
an "extra" URL in a HTMLp page. When so identified, the URL is passed to the extra protocol handler 112c for decoding 
and retrieval of the extra data, which is returned to the HTMLp content handler 114c to render into the page. 

e) The builtin Protocol 

[0429] The builtin protocol provides access to built-in icons and images for use In the SRC attribute of an IMG tag. 
These icons and images are stored In the ROM of the memory 126. The "builtin" text forms the protocol component of 
the URL, and the name of the desired icon makes up the data component of the URL. Fig. 23 Illustrates a preferred 
set of Icons, and the full URL for specifying them. 

[0430] Generally, the builtin protocol hander 112a is invoked as a result of the HTMLp content handler 114c parsing 
a "builtin" URL in a HTMLp page. When so identified, the URL is passed to the builtin protocol handler 1 1 2a for decoding 
and retrieval of the icon or image data from memory 126, which is returned to the HTMLp content handler 114c to 
render into the page. 

C. PORTABLE COMPONENTS 

[0431] Referring again to Fig. 3, the portable components 116 are a set of user Interface entities and other functional 
components that are used to Implement the user interface and storage needs of the wireless communication device 
1 00. The components write to the APIs provided by the portability layer 118, and they serve as the basic implementation 
elements of the MMI 102 while remaining portable for use with different wireless communication devices 100. 

1 . Graphics 

[0432] The graphics system 224 divides the screen display 136 into sections called windows. Windows are arranged 
in a hierarchy, where child windows are wholly contained within their parent window. However, unlike other window 
systems, the window system of the present invention distinguishes between two types of windows: "dull" and "sprite". 
Rather than having every user interface component and window have its own bitmap as in conventional systems, which 
requires more complex bitmap handling, the graphic system 224 takes advantage of the fact that user interface com- 
ponents generally do not overlap. Instead, the graphics system 224 defines some windows (e.g., dialog boxes, or other 
windows that do overlap with other windows and need to obscure them) to have a bitmap (to be "sprite"), while the 
others (the "dull" windows) draw into the bitmap of their nearest ancestor that has one. This distinction reduces the 
amount of memory needed to store user Interface components, and simplifies the process of updating the screen 
display 136. 

[0433] When a user interface element draws to a window, the drawing actually happens to a bitmap in memory 126, 
not directly to the screen display 136. At some point (in the top loop, actually, where the callback queue 110 is proc- 
essed) all the changes to any and all of these bitmaps are transferred to the screen display 1 36. This operation ensures 
a correct and clean update of the screen display 136, and simplifies the underlying video driver, which need only transfer 
the bitmap from memory 126 to the screen display 136. 

[0434] The graphic systems 224 provides the following basic graphic primitives: 

• Lines (thick or thin, arbitrary or special-cased single-pixel-thick vertical and horizontal; horizontal lines, vertical 
lines, and rectangles can also have a fill pattern to let them be dotted or dashed); 

• Rectangles (outline or filled); 

• Bitmaps (single-bit-per-pixel, drawn either as a stencil [a set bit gets drawn in a color, while a clear bit does nothing] 
or as an Image [a set bit gets drawn in one color, while a clear bit gets drawn In another]); and 

• Text. 

[0435] The coordinate system of the screen display 136 is such that coordinates fall between pixels on the screen 
display 136. The result is that if rectangle is drawn from (a, b) to (c, d) and another from (c, b) to (e, d), they will not 

overlap. 

[0436] Text is drawn and manipulated using a data structure called a TextState. Text has various configurable at- 
tributes: 
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• Point size (preset small, medium, and large); 

• Style (plain, bold, italic, underline, fixed-width and strike-through); and 

• Color. 

5 [0437] TextState also stores the drawing position^ which is updated to be just after the string that was drawn, so that 
multiple strings may be drawn one after another without having to compute their width. 

2. User interface Gadgets 

10 [0438] Most of the user interface of a wireless communication device 1 00 may be provided in the form of softkeys 
130 and softkey menus. The content area 214 will generally display text, icons, and HTML forms, and the like. To 
support these features, a number of user interface gadgets 226 are provided: 

• Checkbox: used to implement both checkboxes and radio buttons (radio buttons rely on an external callback to 
^5 know the other radio buttons that need to be deselected when the user selects one) Instantiated in response to 

<INPUTTYPE=checkbox> and <INPUT TYPE=radio> in HTML. 

• Icon: displays a buiit-in icon. 

• LabelLine: a horizontal line with an optional text label in a standard location in a standard font, instantiated by the 
<HR> tag in HTML. 

20 • List: the basis for all the various lists of items in the user interface. Specific list subclasses draw the individual 
items (placed by the List) and determine when the List's selection should be adjusted by a keystroke orothermeans. 

• Popup: implements a popup list of strings from which the user can select one or multiple Items. Each item has a 
string value bound to it. Instantiated by the <SELECT> tag in HTML when the SIZE parameter is 1, 

• ScroMBanner: implements a single-line text banner that can scroll from right to left or from left to right at a specified 
25 speed. Instantiated by the <MARQUEE> tag in HTML. 

• StringLtst: implements the list part of the Popup, but can also stand alone as a scrolling lisL Softkey menus are 
implemented by a StringList. Instantiated by the <SELECT> tag in HTML when the SIZE parameter is not 1. 

• TextEdit: a single-line or multi-line text editing area. Instantiated by the <INPUT TYPE=text> and <INPUT 
TYPE=password> tags in HTML. 

30 

[0439] These entities arc created as needed by the various modules to display various graphic elements. 
[0440] These various types of user interface elements are created by the HTMLp content handler 1 1 4c when a page 
is parsed and in response to corresponding HTML tags. For example, an IN PUTTY PE=TE)CT tag in a page will result 
in a TextEdit object at the appropriate location on the screen display 136. When the user selects the object with the 
35 Up or Down key, it is given the input focus to receive keystrokes input by the user, as such keystrokes are passed by 
the shell 106 to the TextEdit object. 

[0441] Associated with the user interface gadgets are a couple other modules for entering and displaying text. The 
TextEntry module 228 accepts keystrokes and maps them to commands for text input. The commands include display- 
ing provisional (subject to further modification based on subsequent keystrokes) characters and words, and replace- 
^0 ment provisional characters and words, making the last provisional character or word final, and moving the cursor or 
inserting symbol characters. 

[0442] Any entity requiring text input registers with the TextEntry module 228 and then passes nearly all keystrokes 
to it, rather than interpreting the keystrokes itself. Front-end processing for various pictographic languages is handled 
in this module, as welt. 

45 [0443] Another module is the TextWrap module 230, which handles arbitrary regions and wraps text and objects 
inside those regions. This module is primarily used in displaying HTML content, but can also be used for list entries 
that are allowed to wrap over multiple lines. 

3. Data Store 

so 

[0444] Another element of the implementation is the data store 232. The data store 232 is a simple "flat-file" database 
with the following characteristics: 

» Up to 255 fields per record. Fields have both a name and a number, but only the number is used for actually 
55 accessing the data. 

• All records are defined to logically have all fields. As a storage optimization, if no data have been given for a 
particular field for a particular record, the field for that record takes up no space. 

• Each record has a unique identrfier (16-bits at the moment) that is used to gain access to the record. 
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• Database records are not manipulated directly. Instead., functions to get and set the fields of a record are used. 

• A database can have up to eight indices maintained for it. Each index has a selection routine and a comparison 
routine. The selection routine determines which records are part of the index, while the comparison routine is used 
to sort the records in the index. When the index is defined, It specifies which database fields are used by the 

5 selection and comparison routines. When a record Is altered, only if one of those fields is changed will the record 

be repositioned in, added to, or removed from the Index. 

• To access a record, one of two functions is called to get a DataStoreRecord token. 

[0445] When an entity Is done examining or manipulating the record, It calls DataStoreRecordDone. 

10 

4. File Systems 

[0446] The wireless communication device 100 has a file interface that communicates with two underlying file sys- 
tems: 

15 

• A read-only filesystem that is a data structure compiled into the code. ^ 

• A flash filesystem that is spread among flash memory chips of the wireless communication device 100. 

[0447] File access is via a (minimal) familiar set of functions: 

20 

• FileOpen 

• FlleCreate 

• FileRead 
FileWrite 

25 • FlleSeek 

• FileTruncate 

• FileClose 

• FlleDelete 

30 [0448] Each file system is defined by a structure containing routines to call for all the basic operations. The reference 
for an open file contains file system-specific data and a pointer to the table of routines for the file system on which the 
file sits. When a file Is opened, the upper layer examines the name of the file to be affected and chooses the appropriate 
table of routines, then uses the Open routine in that table to open the file. Thereafter, access to the file is through the 
file reference. 

35 

D. PORTABILITY LAYER 

[0449] Referring again to Fig. 3, there Is shown the various modules of the portability layer 118. The portability layer 
118 is designed to make it relatively simple to implement the MMI 102 with an arbitrary telephone control module 120 
*o and real time operating system 122. It provides the following modules: 

1 . Call Control 

[0450] The call control module 140 allows the upper layers to create and manipulate calls, generate DTMF tones, 
f5 and receive notification of state changes. 

[0451] The interface is asynchronous, in the sense that operations are performed on calls, but the success or failure 
of each operation Is reported some time after the operation was requested. 



Table 5: 



Call Control Functions 


FUNCTION 


PURPOSE 


CallCreate 


Attempts to begin a telephone call, given the number to dial. The call can be voice, or data, 
or fax. 


CallCreateHldden 


Like CallCreate, but signals that the call should not be visible to the user. 
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Table 5: (continued) 





Call Control Functions 




FUNCTION 


PURPOSE 


5 


CallRelease 


Attempts to hang up a call. If the call is part of a call group (conference), the entire group is 

hung up. 




CallHold 


Attempts to put a call (or call group) on hold. 


10 


CallResume 


Attempts to take a call (or call group) off hold. If another call or call group is currently active, 
it is placed on hold first. 




CatiCombine 


Attempts to join an on-hold call with the currently active call or call group to form a new or 
larger call group. 


IS 


CallSeparate 


Attempts to extract a call from a call group, making it a separate call again. 


CaliGetlnfo 


Retrieves various pieces of information about an active call, such as what actions may be 
performed on it, its current state, to what number it's connected, the time when it connected, 
the time when it was put on hold, and whether it should be hidden from the user. 


20 


CafI Pickup 


Attempts to answer an incoming call. 


CallStartSequence 


Marks the start of a series of call manipulation steps that depend on each other. If one of the 
steps fails, the rest of the steps in the sequence are not attempted. 




CallEndSequence 


Marks the end of a series of call manipulation steps. 


25 


CallStartDTMF 


Begins generating a DTMF tone corresponding to a particular key. 


CallEndDTMF 


Stops generating the DTMF tone that was previously started. 




Call Enumerate 


Calls a function for each active call in the system. 




CallDataAvailable 


For a data call, returns the number of bytes available for reading. 


30 


CallDataRead 


For a data call, reads available data. 




CallDataWrite 


For a data call, writes data to the network. 




CallSetNotify 


Specifies the routine to be called at the end of each call operation and when various 
asynchronous events occur, such as the arrival of an incoming call. 



35 ' 

2. Message Control 



[0452] The message control module 1 42 allows the upper layers to transmit and receive short text messages. This 
layer may or may not support segmentation and reassembly of larger messages. 



Table 6: 



Message Control Functions 


FUNCTION 


PURPOSE 


SMSCreate 


Given the various parameters of a text message (destination number, body data, body 
fonnat, and options), returns an SMS token for the message that can then be sent. 


S MSCreateFromU RL 


Takes a string of URL-encoded arguments and uses them to create an SMS token for the 
message. 


SMSSend 


Takes an SMS token and sends the associated message. Notification function is called 
when the message has succeeded or failed in its attempt at sending. 


SMSDestroy 


Frees the memory used by an SMS token. 



55 3. Platfonn 



[0453] The platform module 144 provides for platform-specific functions. 
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Table 7: 





Platform Functions 


5 


FUNCTION 


PURPOSE 


10 


PlatMutexInltlalize 


Initializes a variable that can guarantee exclusive access when passed to 
PlatMutexGrab. While the MMI 102 is single-threaded, there are pieces of the 

nnrtshiiitx/ lox/or 11ft ihat max/ nin on a Hifforont thiroa/S Thoco r^or+c r\i tKa ■ mriAr 
jJUi IdUlllly Idytrf I lO Uictl lilciy lUll Ufl d Uiilt^icriU lilicaLl. t ilwoc^ pcti lo Ul Uppcl 

layers that might be called from a different thread (where interrupt-handling code 
is also viewed as a separate thread) use this mechanism to guarantee exclusive 
access to data structures. 




PlatMutexGrab 


Gains exclusive access to whatever Is governed by the mutual exclusion variable 
initialized by PtatMutexInitialize. 


15 


PlalMutexRelease 


Releases exclusive access to whatever Is governed by the mutual exclusion 
variable Initialized by PlatMutexInttiallze. 




PlatMutexDestroy 


Frees up any resources allocated by PlatMutexInitialize. 


20 


Plat Wait ForSomething 


Pauses until PlatHaveSomething is called. This provides a hook for the portability 

Inv^r lift to chi it Hnwrt or \/i<^IH control of tho nro^^^<£or co tKo imrtor loxfAro Hr> not 

waste processor time unnecessarily. 




PlatHaveSomething 


Releases the upper layer it it is waiting in PlatWaitForSomething. 


25 


r lairiinyriay 


Plays a ring tune or other sound through the system's speaker. Sounds are defined 
by an index, a volume level, and whether vibration should also happen. 127 sounds 
are defined as system sounds (keyclicks and error sounds, for example), while 127 
sounds are defined as tunes for the phone ringer. Returns immediately, allowing 
the sound to play in the background. 


30 


PlatRingStop 


immediately, allowing the sound to play in the background. 




PlatRingGetNumberOf Rings 


Returns the number of phone ring tunes that are supported/defined. 




PlatRlngGetName 


Returns the name of one of the phone ring tunes, for displaying to the user to allow 
her to select a default ring, or a ring for a particular person. 


15 


PlatGetPowerStatus 


Retrieves the current state of the battery and AC adapter immediately, allowing the 
sound to play in the background. 



4. Timer 



[0454] The timer module 146 provides basic timing services that allow the upper layers to receive a function call 
after a specified amount of time has passed. 



Table 8: 



Timer Functions 


FUNCTION 


PURPOSE 


Timer Alloc 


Allocates a timer that can be used repeatedly. Sets the routine to be called when the timer 
expires. The routine is called synchronously via the callback queue; it does not interrupt other 
operations. 


TimerStart 


Specifies the next timeout interval for the timer, In milliseconds. After approximately that 
amount of time, the routine specified In TimerAlloc is called. 


TimerStop 


Stops a timer from firing. If the timer has already fired, and a call to the timer routine is in the 
callback queue, the call is removed from the queue, so there Is no need to handle getting a 
call after having stopped the timer. 


TimerFree 


Frees up an allocated timer. If the timer was running, it is also stopped. 
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Table 8: (continued) 



Timer Functions 


FUNCTION 


PURPOSE 


TimerGetSeconds 


Returns a 32-bit counter of seconds. The counter does not need to be relative to anything in 
particular, so long as it increases steadily once each second. 



5. Display 

10 

[0455] The display module 148 manages the screen display 136. 



Table 9: 



Display Functions 


FUNCTION 


PURPOSE 


Display DriverBlitIn 


Copies part of a bitmap to a point on the display. 


DisplaySetBacklight 


Tums the display's backlight on or off. 


DisplayDriverSetContrast 


Sets the display's contrast to the specified value. 


DisplayDriverGetContrast 


Retrieves the current contrast for the display. 



6. Flash Driver 

[0456] The flash driver module 1 50 allows the upper layer file system module 234 to read and write the flash memory 
chips on the wireless communication device 100. 



Table 10: 



Flash Drive Functions 


FUNCTION 


PURPOSE 


FlashDriverlnitialize 


Lnitializes access to the flash memory. 


FlashDriverGetlnfo 


Returns information about the flash driver and the device it is driving. It includes: 

• The number of erase units in the device 

• How big each erase unit is 




• If the device reads and writes in pages, rather than on arbitrary byte boundaries, the driver 
can specify the page size. 

• If either the device or the driver supports error-correction for written . pages, the driver can 
indicate this to the flash file system. 


FlashDriverErase 


Erases an erase unit of the device. It may happen synchronously or asynchronously, but in 
either case a callback function is called when the erase is complete, indicating if the erase 
was successful. 


FlashDriverWrite 


Writes a number of blocks of bytes to an erase unit in the device. If the device reads and 
writes in pages, the size of the blocks will always be a page size, though the driver may have 
to provide harmless bytes for one or more of the blocks that make up the page. 


FlashDriverRead 


Reads a number of bytes from an erase unit in the device. 



7. Config Protocol Handler 

[0457] This protocol handler 112b allows C code and HTML to get and set configuration settings of the wireless 
communication device 100. These settings are the ones implemented by the upper layers, and the module communi- 
55 cates other settings to lower-level code as needed. Because of its need to access configuration settings, the conftg 
protocol handler 112b is preferably located in the portability layer 118. 

[0458] A config URL may address bits within a device setting, both for getting and setting. A config URL has the 
following syntax: 
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CO nf i g ; setting. bitnumber:bitsize 
[0459] If -.bitsize is not present. 1 is assunned. Bitnumber runs from 0 to 15. with 15 being the most-significant bit. 
[0460] Most settings may be fetched by any module or page that needs them, though some configuration setting, 
such as the telephone's PIN number, may only be obtained by URLs with sufficient privilege (typically HTML files that 
are in the device's ROM). No device setting may be set without sufficient privilege (again, typically by HTML files that 
are in the device ROM). 

[0461 ] The following are a set of preferred configuration URLs for invoking respective functions of the config protocol 



handler 112b: 


Table 11: 


Config Protocol Handler Functions 


FUNCTION 


PURPOSE 


ConfigGetlntValue 


Retrieves an integral configuration setting. 


ConfigSetlntValue 


Sets an integral configuration setting. 


ConfigGetStringValue 


Retrieves a string configuration setting. 


GonfigSetStringValue 


Sets a string configuration setting. 


ConfigParseSettIng 


Parses a string reference to a configuration setting, yielding the data type of the setting, 
and. for integral settings, which bits of the value to affect or fetch. 


ConfrgCheckPassword 


Examines the arguments from a URL for a password and compares it against the 
password stored in the configuration settings. 


Conf igConf irm Password 


Handles obtaining a password from the user and resubmitting a URL with a password 
attached (to be examined by ConfrgCheckPassword) 



[0462] In summary, the present invention provides a system, various methods, and a software product that substan- 
tially enhances the flexibility and functionality of wireless communication devices. The present invention, including the 
use of protocol handlers and content handlers, provides a system and software architecture in which all features and 
functionality of the wireless communication device may be accessed and manipulated through a markup language 
based user interface. The extended features of HTMLp and the HTMLp content handler specifically allow Web and 
other content to be easily displayed on the small screen display of a wireless communication device, and enhance the 
menuing, navigational features, and the fomi handling features of HTML. By providing access to telephone or other 
functionality of the wireless communication device through a markup language-based user interface, the present in- 
vention allows sen/ice operators to easily and quickly generate new user interfaces and custom feature sets for different 
wireless communication devices, without requiring the expertise, software development environment, or software man- 
agement problems of conventional MM Is. Further, the present invention allows service operators and manufacturers 
to quickly and efficiently brand wireless communication devices as desired, again without requiring creation of different 
MMI software for each service operator. 
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10 



15 



20 



25 



30 



35 



40 



APPENDIX A 
The Shell Funcn'ons 

The shell 106 offers many functions for the other parts of the present invention to use 
to process keys, manage the URL history stack 108, and handle other data. They arc described 
brieflv as follows: 



Key Frocesswg Functions 


r ufN^ I i\jri 




onciix^rocessrvcy 


/accepts KeysiTOKe iroui ine porLauiiuy idycr anu posses 
it to the first entity in the keypad target list. 


ShelJGrablnpur 


Registers an eniity as interested in receiving keystrokes. 
The keypad target list is processed in LIFO order. An 
entity is defined as a table of two routines plus a void * 
those routines can use for anv Durnose The two routines 
arc: 

ProcessKey, which actually receives the keystrokes. 

GrabChange, which is notified when the eniity is oris 
not at the head of the keypad target list. 


ShellReleaseinpui 


Unregisiers an entity from ihe keypad target list. 


ShellPrcviousinput 


Passes the keystroke to the entity that registered before 
the one calling this function. When called -from a content 
handler's ContentProcessKey function, the shell will 
process the keystroke according to the system-wide 
defaults. 



50 



55 



URL Stack Management 
Function Purpose 



ShellGctURLWithDataAnd Fetches the data associated with the URL and hands 
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URL Stack Management 
5 Function Purpose 



10 


Flags 


control of the content area lo the handier for ihe lype 
of content that is relumed by the protocol handler, 
placing Ihe URL at the top of the URL slack. 


15 




In addition to the Contents iream returned by the 
protocol handler, the content handler receives the 
ShellExtraData passed to this routine. 


20 
25 
30 




The caller also passes a set of flags that contain the 
priority of the URL (how imponant it is to display the 
data: if the URL stack contains a URL that is of higher 
pnoniy, inc leicmng aJici ciispxay oi inc udia associateu 

with the passed URL is delayed until the user has 
removed the higher-priority URL from the stack) and 
the privilege level at which to fetch the passed URL. 


35 


ShellGetURL 


Fetches the data associated with the URL and displays 
it, passing no extra data and using the priority and 
privilege of the URL at the top of the URL stack. 


10 


ShellGeiURLFlags 


Gets the flags (priority and privilege) for the UTIL at 
the ton of the IJRI <;tack 


'■5 
•0 


ShellDispIayConiem 


This is the moral equivalent of a dialog box in the 
present invention. It allows you lo bring up a content 
handler directly without having to have a protocol 
handler and URL involved. The content handler 
receives the same flags and privilege as is enjoyed by 
the URL that is bringing it up. 


5 


ShellGeiURLSiream 


Fetches the data associated with the URL without 
changing what's displayed in the content area. 
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URL Stack Management 
Function Purpose 

5 



10 


onciix\.crun 


I7^fi»r/'K^c tK/k W^r^ frvr rrt^ tr^rt T I rsn I iT? f rftr*!^ 
IxCXClCnCd inc Uala lUl lUw lUp \J k\-J^ \J\\ L.11C V-JrvX. SlaCK 

and causes it to be displayed again. 


15 




Prin« ftn^ e\T mnrp 1 TT? T ' c frrMn rh^ t IT? T cTarlr TK^ 

J^v/UO V/iiw L'l iilUlw J\J_ ^ iWJXll IJJw i^XVJi^ i ilC 

caller passes a parameter that says whether to simply 
remove the top-most URL, all URL's involved in the 
current interaction (see section Error! Reference 
source not found.) or all URL's but the very first. 


20 


ShellGoBackScring 


Lilce ShellGoBack, but accepts a dynamically- 
allocated string. 


25 


ShellPopURL 


Pops a specific URL off the URL stack. 




ShellMarkTop 


Marks the current URL as the start of a complex 
interaction, all components of which can be popped 
uom liie S13CK a.i once oy passing inc appropnaic 
argument to ShellGoBack. 


55 
40 


oticiiiv^idi K I cinp 


most URL. When a URL is marked temporary, any 
attempt to fetch another URL will cause the temporary 
URL to be popped from the stack before the new URL 
is displayed. 


45 


ShellPuiURL 


Stores data for the passed URL. Does not affect the 
URL stack. 


50 

55 


ShcUSciStatc 


Records a block of state to be associated with the top- 
most URL on the URL stack. The content handler for 
the URL is responsible for freeing and altering the 
contents of the block; the shell merely tracks the 
address. 
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URL Stack Management 



5 


Function 


Purpose 


10 


• 


The inient is to allow ihe user lo return to the same 
visual place when she pops back to this URL. The 
shell does not attempt lo cache URL data returned by 
protocol handlers. 


15 


SnellGctSiate 


Retrieves the block of state for the lop-most UHL, as 
was set by calling ShellSetState. 


20 


ShellGetExrraData 


Returns the pointer to the extra data that were passed 
with the top-most URL. 








25 


URL Generation & Decomposition 




Function 


Purpose 


30 
35 


ShcIIParscURLArgs 


Begin parsing the arguments that were encoded in a 
URL, Arguments are of the form ^'name^value*\ with 
multiple arguments separated by characters. 
Arguments usually follow the first *?' in a URL. 


to 


ShellGeiNextURLArg 


Fetches the next argument from the argument list, 
using the token returned by She 11 Parse URL Args. 




She! )Done\y ithURL Args 


Finish parsing arguments from a URL. 


0 


ShellFindURLArgs 


Shorthand function that will search a U^RL argument 
string for specific arguments and return their values. 
Some arguments may be marked as mandatory, 
causing no values to be relumed if not all the 
mandatory arguments arc present. 


5 


ShellBeginURLArgs 


Begin constructing a URL argument list. An initial set 
of name/value pairs may be given in this calL 
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\JKL Generation &l Decomposition 


5 


Function 


Purpose 


10 


ShellAppendURL^^Jg 


Adds another name/value pair lo the argument list 
that's being built. 




ShellFinishURLArgs 


Returns the now-complete argument string with all 
name/value pairs suitably formatted and encoded. 


15 
20 


ShellPrependURLToArgs 


Specifies the URL for which these are the arguments. 
ShellFinishURLArgs will return the URL with the 
arguments attached. 


25 


Shel 1 EncodeURL Arg 


Encodes a string for inclusion in a URL argument list. 
This is used by ShellAppendURLArg and 
ShellBeginURLArgs, but is also made available for 
general use. 


30 






Content Stream Management 




Function 


Purpose 


35 


SheliCreateConientSiream 


Allocates a ContentStream structure for a stream of the 
passed type. 


40 


ShellCloseConteniStream 


Closes a content stream and frees the ContentStream 
structure. 



45 



Softkey Management 


Function 


Purpose 


ShellDefmeKeyGo 


Requests that a softkey be given a panicular label, and 
when the key is pressed, the current content handler's 
ContentActivatc function be given the passed string. 
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SoFTKEY Management 


5 


Function 


Purpose 


10 


ShellDefineKeyBack 


Requests thai a sofikey be given a panicular label, and 
when the key is pressed, ShellGoBack be called with 
the passed argument. 


IS 
20 


ShellDefineKeyMenu 


Requests that a softkey be given a panicular label, and 
when the key is pressed, it bring up a menu with the 
passed entries. When one of the ennies is selected, the 
current content handler*s ContentAciivate function is 
called with the siring specified for the selected entry. 


25 


ShellDefineKeyNothing 


Requests that a softkey have any previoiis binding 
removed. 








30 


Miscellaneous Screen Elements 


Function 


Purpose 


35 


ShellDispiayStatus 


If the status message area is visible, the shell will 
display the passed message in that area. 


to 


ShellDisplayTiile 


If the title area is visible, the shell will display the 
passed title in that area. 




ShcllSetScroIlable 


Lets the user know whether the conteni can be scrolled 
in either direction (up or down). 




ShellSelNcwMail 


Show or remove the new-mail icon from the screen. 


to 

■■5 


ShellEnlargeContent 


Requests that the content area be enlarged to take over 
the indicated pieces of the screen. The takeover lasts 
until the next URL is displayed and is not 
automatically reestablished when the URL making the 
request is redisplayed. 
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Text Entry Modes 


5 


Function 


Purpose 


10 
15 


ShellSetTexcEntryMode 


Changes the global texi-entry mode and updates the 
mode indicator on the display. The shell itself does not 
act differently based on the mode, but it is the 
custodian of the current mode sening that other pans 
of the present invention consult. 


20 


ShelJSetTextShiftState 


Sets the shift state that is used by other pans of the 
in^vention. The shift state may also modify the mode 
indicator the shell displays. 




ShellGetTextEniryMode 


Fetches the current text entry mode. 


25 


ShellGetTexiShiftState 


Fetches the current shift state. 


30 


ShellSeLModeSequencc 


Specifies the sequence of modes through which the 
shell should cycle when implementing the default 
processing for the "mode" key. Anywhere from one to 
all three modes may be specified. 


35 
40 


ShellEnforceModeSequenc 
e 


Ensure that the global mode is set to either any of the 
modes in the current sequence, or to the first mode in 
the current sequence, depending on the passed 
parameter. 



Idle-Time Processing 


Function 


Purpose 


ShellAddldleHook 


Requests that a function be called after a specified 
number of seconds have passed without any user input. 


ShellRemoveldlcHook 


Removes a function that was previously registered 
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Idle-Time Processing 


Function 


Purpose 




with ShellAddldleHook. 


ShcllDisableldlc 


Disables all idle-time processing. This may be called 
multiple times, but each call must be matched by a 
corresponding call to ShellEnableldle. 


ShclIEnableldle 


Re-enables idle-time processing if there are no more 
outstanding calls to ShellDisableldle. 




Miscellaneous Functions 


Function 


Purpose 


ShellPowerOff 


Pops all URL's off the URL stack and asks the 
portability layer to power off the device. 


ShellStandardDiaiog 


Brings up a full-screen dialog in a standard format. 
The caller can specify the message, the style of-dialog 
desired, what to do with the softkeys» and a time 
without user input after which to take a default action. 



Claims 

1. A browser program product for controlling the operation of a wireless communication device by execution of the 
browser by a processor of the wireless communication device and displaying a page of markup language data, 
the browser executing the operations of: 

receiving a markup language page including a plurality of hyperlinks; 
selecting a hyperlink of the markup language page as a current hyperlink; 

scrolling the markup language page in a direction on the screen display in response to a user input to display 
only a portion of the markup language page; 

determining whether a next hyperlink in the direction of scrolling is visible; 

responsive to the next hyperlink In the direction of scrolling being visible, making next hyperlink the current 
hyperlink; and 

responsive to the next hyperlink in the direction of scrolling not being visible, scrolling a portion of the markup 
language page. 

2. A computer implemented method of navigating a page of data including at least one selectable hyperlink, in a 
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computer system including a screen display but not including an independent cursor controlled by a peripheral 
pointing device, the method comprising: 

scrolling the page in a direction on the screen display in response to a user input to display only a portion of 
5 the page; and 

automatically and iteratively assigning a next visible hyperlink in the direction of the scrolling and in the dis- 
played portion of the page to a user selectable key. 

3. A computer implemented method of navigating a page of data including a plurality of fonn fields, each form field 
10 having a type, in a computer system including a screen display and a keypad having a plurality of keys, but not 

including an independent cursor controlled by a peripheral pointing device, the method comprising: 

scrolling the page In a direction on the screen display in response to a user input to display only a portion of 
the data file; 

*5 determining whether a next form field in the direction of scrolling is visible; 

responsive to the next form field in the direction of scrolling being visible, making the next form field a current 
form field for receiving a user input; and 

assigning an action for manipulating the current form field to a key of the key pad according to the type of the 
current form field. 

20 
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HTMLp 



Result 



<HTML> 
<HEAO> 

<KEY KEY-2 LABEL- "PhoneBook- ACTIOH»*f ilc : //phonbook .html " > 
<KEY XJKBEL--Menu- ACTIOH-MENO> 

<KEYMENU KEY»1 LABEL- *K«5S»ge s - ACTION- f ile : //msqs . hcml > 

<KEYMENU KEY^l LABEL--Recenc Calls'* ACTICN»file : //recent , html > 

<KEYMEHU KEY-1 LABEL-"Phone Sercings" ACTION-- file :/ /phonsett ..it.nl"> 

<KEY KEY -up accion*" rile: //recent. html ••> 

<KEY KEY-<lown act ion-"f ile : //phonbooic, ht»ai-> 

</KEAO> 

<BO0Y> 

<img src-Jile : //space . gif><br> 
<img s rc-f ile : //sp^ce . gi/><br> 
<CENTEK> 

<IwG SRC-"f ile://la-air .giX-><br> 
c e 1 1 u 1 a z<br> 
services 

</CEHTCR> . " 

</BODY> 

</HTML> 
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HTMLp 



<HTML> 
<HeAO> 
<TOP> 

<TITLE>Phone BooJc< /TITLE> 

<KEY KEY-1 Label-New Accion- "new"> 

<KEY KEYs«cIear action»delece> 

<HELP>Press any number key co searc.*i for an 

entry</HELP> 

<HELP>Press Send co call someonc</HELP> 

</HEAD> 

<BODY> 

<OBJECT CODE»"pnone :iisr ?eclickey*24showscacus''> 

</BODY> 

</HTML> 
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HTMLp 


Result 


<HTML> 

<he:ao> 

<KCY LABEL- I<3nore ACTIOM»phone: ignor«> 
err TEST-exrra :conf > 

<K£y KEY-l LABE2.-Confersnce ACTrON>plione:conf ecence> 

<else:> 

<KEY KEY*1 LABEL--Pick Up" ACTION*phone : answer> 

</ir> 

<Xiy KEY-send ACTION»pnone:answer> 
<ir TEST-conrig:anykey> 

<KEY r.EY-dcrault ACTION»phone : answer > 

<KEY XCY^'back ACTION-phonc : answeo 

</IF> 

<KEY KEY-erx<l ACTION-phone:igaorc> 
<KEY KEY-op ACT ION -phone :,upvoiume> 
CKEY KEY*dowf\ ACTION-pnone :clownvolume> 
</HEAO> 
<BODY > 

<TEMPLATE> - ' 
<CENTER> 

% (excra:name) <bc> 

<lm9 SRC'excra :oi9icon><Dr> 

<imq src- £xle : rxnqpalt (excza :pal > .9if> 

</CENTER> 

</TEMPLATE> 

«/aoDy> 

</HrML> 
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HTMLp t Result j 


<HTML> 
<HEAO> 
<TOP> 

<TITl^>Phone BooJc< /TITLE> 

<KE:Y label- "Modify" AC7rON-MENU> 

<KEY:4EKU KEY-1 label- -Add Another tf" ACriON--phone ; edi c ?Kafne-»?n"> 
<KEVMEMO KEY-1 LABEL- "Assign Speed Dial" 

ACTICM-"filc : //pl3Speed.hcna?id*ei4or ;sec"eoiNaine-en4icon-(?I"> 
<KEYMENC KEY-1 LABEL- "Scc Rang Tone ** 
ACTION- "file : / /pDr i.ng . hcnU ?id-Gi 4Name-t»n'*> 
<KEYMEMi; KEY-l LABEL- "CHange Number- 

ACT I OM-" file : //pbnum. hcml ?id»»i4of fset*0oxMaiiie»tfntPhone»eN*"> 
<KEY KEY-2 LdtDcl-New Action- "new •> 
<KEY KEV-cZear action-delece> 

<HEL?>Pr€ss any number Hey to search tor an encry</KELP> 

<HEL?>Press Send to call someone</HELP> 

</KEAO> 

<aoDr> 

cCBJZCT CODE-"pnonc : list ?shovrstatus*> 

</QODY> 
</HTXL> 




► OA4d Anottier^ 

^ Assrgn Speed Dia 1 
©SelRing Tone 
OChonge Number 
Sefecf r Uew 


3 





FIG. 10 



HTMLp 


Result 


<HTML> 
<HEAD> 

<rop> 

<KEY KEY-1 Lai>el-New Actxon-*'new > 
<KEY KEY-clear accion-oelece> 
</HEAD> 

<aoDY backg round file . / /logo.fjify 

<IMG SRC--f jlIc : //book.gif " ALIGN-boct ore neignt>lS KSPACE-2> 
<b>P h o n efcnt>5p;fi o o k</ti><br> 
tnbsp; ^OBJECT 

CODE> "phone : list ?edity.«y*2& snows carus I eclic\2rl» file : //pbeciT ..T:nii?id 

-9i *2 6of f 5e-c-tfo\2 6Ndme-?ni2 6speed-es\26icon-i?I\26Phone-9K%26rin9-er 

%26prio-eR** widtn-101> 

</BCOY> 

</HTML> 




52223333 ' f 

^ Doily Horotcope Q;^ 
Hew 1 Edit 





F/G. 7y 
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HTMLp 

<HTML> 
<:KEAD> 

<TITUE>Sct BacJclight</TITLE> 

</HEAD> 

<BOOY> 

<TEMPLXTE> 

<FORM METHOD- POST On-" con £ i q : se c " > 

Backiignc snould be:<Dr> 

<input type-raaio r.ame-"bacKiighc" CHECK£E>-''cont ig : backlight-O" 
value*0>On when xn use<dr> 

<input: cyp«"^*^io naBie»''Daciclight" CHECKED-''conf ig roacklighc-l" 
valuc*'l>On when in uac or chacqi.ng<br> 

<inpuc type-radio name^'backlight** CHECKEO= "con Cig: backlight* 2- 

value-2>Of f <br> . - 

<bE> 

Delay: <inpuc type-cexc name-" backlight delay- 
value-" "k iconcLq tbacKlighc delay) "> 
< input type-suomxt name-OK valuc-OK> 
</rOEVM> 
</TEMPLATE> 
<yBOOY> 
</KTML> 



Result 



Set BpckUght 



sacxiigni snouid be: 
► <3> On when n u$c 

Q On when m use or 

horgra 



Detay: 15.. 



FIG. 12 
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HTMLp 

<HTKL> 

<rJtC SRC»bbo<Jy .html> 

<cencer><fonc si.re» I >I n iorma tx on Scrvices</f oncxbrx /cenceo 
<rORM ACTION-phone : xn<li r> 
<SELECT SI2E-3 MAME-uri SIMPl-O 

<OPTION VALUE-http: //svcs/traf f ic.ftt3ii>Traf f ic Watcn</OPTIOM> 
<OPTI0N VALOE-http: / /svca /billing .hc«a>Billing Ir.qui.ries</OPTIOW> 
< OPTION VALOE-htCp: / /s vcs /portfolio. ntna>ScocJc Portfoli.o</OPTION> 
<OPTION VALOE-http: //svcs/weACher.htmi>Local Wcachec</OPTION> 

</se:lect> 

<INPUT TYPE-submit K£Y-send> 
</rORM> 

<IMC SRC-endbbody .htrai> . ' 

</HTML> 



Clla bbody . htjnJ. : 

<• Specifies a cocy surrounaea by a oocaer with the operato* 
logc at Che ccp. The incluamg file can aad a suDcap^ion 
inaneaiacely beicw, tiuz left ana r.gnc margin are sec so text 
will noz impir.ge on tne boraer > 

<BODY BACKGROUN0=sq-bAClC . gil BG?ROPERTIES»Cixe<l> 

<BLOCKOUOTE> 

<BR> 

<INC SRC» stdlooo- hcral> 



£xlo endl^body . h Ukl : 

<: Closes tne tags chat were opened by bbody.ntal> 
</BL0CKQt;OTE> 

</BO0Y> 



Cxla a cdlogo . ntaX : 

<! Provides the operator logo with che text flow set to 
receive a subcaptxon for the loqo > 
<l«G SRC-l-airtel . gif > 
^ <BR> * 



Result 



123 I 



Iniormouon Services 
>^ Traffic Watch 

Billing Inquo-ies 
Stock Porf folio 



FIG. 13 
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HTMLp 

<HTML> 

<HeAO> < T ITLE> Oi a img < /TX no 
<TEMP> 

<KEY KEY-l Labcl-"Recenc- Action-" file : //recent ►hcml " > 

</KEAD> 

<BODY> 

<FORM ACTlON-"pnone:dial"> 

<IHPUT NAMC»num TyPE«phonenujii> 

<INPUT TYPE-submit KEY-sena> 

</rORM> 

</BO0Y> 

</KTML> 



Result 





123 


Bortvo 








FIG, 14 
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1504 




FIG. 15 
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HTML 


Result j 


<HT«L> 

<eoDy> 

<rORM METHOD- POST ACTIOM-^ht cp r //cgi - 
ba.n/purcnase"> 

Name; <ltt?lJr TYPE-TEXT KAWE-naitte><br> 
Address: <rNPCT TYPE-TEXT N AME-s c re« t ><b r> 
Cicy: <IMPUT TYPE-TEXT NAME-cicy> State: 
< INPUT Tr?E-TEXT MAM£>5Cate MAXLENGTH-2 
SI2E»»2> Zip: <INPUT TY?E*TE:CT NAME-sip 
SIZE-5><br> 

Credxc Card: ciNPfT TYP::-RA0IO 
NA«E-caratyp« VALUE-visa>viSA <INPUT 
TYPE-RADIO NAME-cardtype 
VALUE-moMasterCard <IHPOT TYPE-RADIO 
NAME-cardtypc VALUE-amex>Araerican 
Expres3<t>r> 

Number: < INPUT TYPE-TEtCT HAMC-cnurttaer><t>r> 
< INPUT TYPE-submxc name*ouy 
value-9uy></rOPJ4> 
< /BODY> 
< /HTKL> 


Name: \ 
Address: | 

Ckr\ Stale./ Zip: | 

Credtf Card. ^ VISA MartcrCwd Amcncaa Express 

Number 1 ^ ^ 



F/G. ^6 
PRIOR ART 
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CnE^fT Server 



<HTML> 
<HZAD> 

<TrTL£:>Purcha5e S kis </TITLE> 

<TOP> 

</H£AD> 

<BODY> 

Please enter your name: 

<IN?UT TYPE-TEXT NAME-name SirE-25><br> 
< INPUT KEY-send TYPE«sudinic> 

</roR«> 

< / 30t)Y> 
•f /HTML> 




GET hctp : / /sk.isnop/cgi-t>in/aadr rr.ame-George-f Will 






iiucn numc inio inc ri I ML 
cempbce mainwincd on ihc 
server, upload to client. 


<HTML> 
<HEAD> 

<TITLE>Purcf\a5e Skxs</TrrLE> 

</HEAD> 

<BODY> 

Now we need your address: 

<FOl^M METHOD-GET ACT ION -"h c tp ;// s )ci shop/ cgi - bin / cr edi c "> 

<INPUT TYPE-hidden NAME-name VALUE«"George Will''> 

Scree:: <I^^PUT TYPE'TEXT NAME -street Siie-3><br> 

Ci::y: <INPOT TYPE-TEXT NAME-Clty Si:e-10><br> 

State: dNPUT TYPE-TEXT NAME-Stace MAXLE:iCTH»2 SIZE-2>cbr> 

Zip: <IMPOT TYPE-TEXT NAME-2ip Sr2E-S> 

<XNPUT KEY-5cnd TVPE-5ubnu.t> 

</FORM> 

c/BODY> 

</HTML> 




GET h- ip: / /skishop/cgi- 

bin/credit ?name=G€orge'»-Will4streec«2+Anywhereici c 
y=Madison&stace=WI&2ip=53705 






Inscn address parameters into 
the tcmplaic maintained on the 
server, and upload to client. 



FIG. 17a 
PRIOR ART 
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Cljent Server 



< HTML> 

< K£A0> 

<TlTLE>Puccna5e Sfci s<./TITI.E> 

< / HEAO> 

<BOOY> 

FAnaily. yoor creOiC card info: 

<FORM METHOO-GET ACTION'^h crp : //s jcishop/cgi-bin/ccnfirin'*> 
< INPUT TYPE«nidden NAME-name VALUE«'*Ceorge HjLil''> 
<1MPUT TYPE'hicdcn NAME-scrcet VAL0E--2 Anyvnere"> 
< INPUT TYPE»hidd«n MAME*city VALUE -"Mada son "> 
<INPUT 7YPE»hLdden NAME-scace value-'wi - > 

<IHPUT TYpE-hiGden NAME«=i.p VALUE--S3'705''> 
Credit Car3:cbr> 

< INPUT TYPE-RAOXO NAME-cardcype VALOE-vt sa>VISA 
<INPUT TYPE-PJ^CrO NXME-carc zype VALUE-moMastcrCacd 

< INPUT TYPE»PA0IO MAME-cardcyp< VALUE-amex^AAierxcan 
Cxpres3<t>r> 

Number: < INPUT TYPE-TEXT NAME-cniaiRber > 

<IWPUT KEY*ser.d TYPE-suBiriC namcouy vaiue-''RevieW> 

</FORH> 
</BODY> 
</HTKL> 




GE:t ncLp w / sk:.sno?/cgi- 

bin /credic ?r.ame=George-^Wiliiscreec = 2+Anywhereicic 
y=Madison& scaEe=Wli2ip=*53'/056cardt vpe*visa&cnuinbe 
r-7732222156661000 






I Insert credit card panimcicrs 
inio lemplate maintained on 
the server^ and upload lo 
cHenc. 


<HTML> 
<HEAD> 

<TITLE>Cor.fi.rir. Order</TITLE> 

< /HEAD> 

<800Y> 

<DL> 

<DT>Namc;</DT><00><b>George Will</c></DD> 
<DT>Addrcss: </DT><0O><b>2 Anywnere, Madison, WI, 

53?OS</t»</DD> 

<DT>Cr€<lit Care: < /DT><DD><b> VISA<bc> 

77 322C31566elO(>0</iJ></DO> 

</0L> 

<rORM METHOD- POST ACTrON^'hCCp : //ski3hop/cgi -bin/purchase-> 

< INPUT TY?E-hj.tJdcn NAHE-nam« VALOE--Ceorg€ Will-> 

<INPUT TYPE-nidden MAME-screec vaLUE-'-Z Anywhcre''> 

<INPUT TYPE-hidden NAME-cxty VALUE--Madi5bn*'> 

<INPOT TYPE-r.xdd«n NAME-sca^c VALVt'^Ufy 

<IMPUT TYPE-hidden NAME- tip VALUE--53705-> 

<INPUT TYPE-hLdden NAME*cacdCypc VALOE-''visa''> 

<INPUT TYPE-t\xdd«n NAME-cnumoer VALUE-"?? 322221S66filO00"> 

<INPUT KEY-1 TYPE-suo»xc name-buy vaiue--Buy t "> 

</FOPJi> 

</BOOT> 

</HTML> 




POST hccp: / /skishop/cgx- 

bin/purchas€?name=Georgei-Wiilfcstre€t=2"»'Anywhereic 
i t y»MadisonsscdCe=wi&zip«33705icardtype»visatcnum 
ber=7 7 3222 2 15 666 1000 




Process o-ansaction with all 
parameters. 



FIG. 17b 
PRIOR ART 



3IDt <EP 1 1 52332A2_L> 



78 



# 



EP 1 152 332 A2 




HTMLp 



Result 



file: purcnaseiorni.ntai 

<HTML> 

<HEAO> 

<TITlE>Purcftase Skis</TIZLV> 
<TOP> 

<KE:Y KEY-I LABEL=»"Never Mind" ACTION-clon«> 

</HEAD> 
<BODY> 

Please enter your narae: 

<rORtt METHOD-NEXT ACTION*" f i le :/ /addr . hcmI-> 

< INPUT TYPE»TEXT NAME-name cap-name abcRioae5«alpha, num 

SI2E-25><br> 

<IHPUT KEY-sena TYPE-suamic > 

</roR«> 

</BODY> 
</HTML> 



PurchoseSkis 



^ tease enrer your name: 
►•George Will 



ziic: dcoi.ninii 

<HTML> 

<HEAD> 

<TrrLE>Purclnase S Jcis< /TrTLE> 

<KEY KEY-2 LABcL-'Never Hxna" ACTION-done> 

</HEAO> 

<BO0Y> 

Now we need your address: 

<rOR« METhOD-NE.XT ACTION- " fi i e :/ /credi c . h cmi " > 

Street: <INPUT TYPE-TEXT NAME-screec cap-name abcmodes-nura, alpha 
sirc-9><br> 

City: <rMpUT TYPE-TEXT NAME-cicy cap-name abcmodes^alpha 
sire- 1 0><br> 

State: < INPUT TYPE-TEXT NAME'SCace Cap-name abcntodes -alpha 

KAXLENCTH-2 S12£-2><br> 

Zip: ciNPUT TYPE-TEXT NAME-rip abcmodes«num SlZE-5> 

<IMPUr KEY-send TY?E-sutoait > 

</roRrt> 

</BO0Y> 
</HTML> 



iHeverMind 



PurchazeSkis 



f^ow we neea your 

treet: 2AriywheTe 
City: Madiibn 
State: VJ\ 
2 fp: ►537051.. 



123 



INcweiMmd 



iLle: creQit.ncml 

<HrML> 

<HEAD> 

<T1TI.E> Purchase Sicis</TITLE> 

<KEV KEy-2 LASEL-'-Ncver Mind" ACTrON-done> 

</HEAD> 
<BOOY> 

Finally, your credit card info: 

<roPM METHOD-NEXT ACTION-'file : //conf irm.hc»l -> 
Credit Card:<br> 

< INPUT TYPE-RADIO NAKC-cardcype VALUE- visa> VISA 

<INPUT TYPE-RADIO NAME-cardtype VALOE-mOMascerCard 

<INPUT TYPE-RA.DIO NAM£-catdcype VALUE -amex> American Express<bc> 

Numiser: < INPUT TYPE-TEXT NAME-cnumber a23C3BodEs-nuni> 

<:INPUT KEY-send TYPE-subnuc name*buy value»''Review''> 

</FORM> 

</BODY> 

</HTML> 



i ^ taoO Q iiQfl 123 



PurchoseSkis 



-inoKy, your creaif card 
info: 

Credit Cord: 

©VISA 
► O MosterCord 

O American Express 
SJumber: 2)55661000 
Select (Never Miftd 



FIG. 18a 
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HTMLp 


Result 


<HTML> 
<HEAD> 

<TITLE>ConCirin Oraer</TITLE> 

<KEY KEy-2 LABEL-*Never Mind" ACTION-done> 

</HEAD> 

<teniplace> 
<DL> 

KUT^Haulc • < /DT>^DOXt>>% (ftxCTA : name) </bx/DO> 
<DT>Aadre3S :</0T><OD><b>i (extra: streec) , ( extra :cicy) . 
% (excraiscace) , \ { extra : zip i </b></DD> 
<DT>Cr«dxt Card:</OT><DO><b><:if 
tesc«excra:cardtype-vis*>viSA</if><if 
te3C-excra:cardtyp«-mc>MastecCaco</if xif 
ces c-extra:ca rdtype-«mex>AmeEican Exprea3</i f ><br> 
1 (extra rcnumtoeri </l»</DD> 

</DL> 

</cempIate> 

<FOBM METHOO-POST ACTIOM-'hctp : //cgL-bin/purcfta»e'*> 
< INPUT KEY-1 TYPE-suDoic name-buy value-"Buy ! '> 

</FCRM> 
</BODY> 
</HTML> 




Mame: 
Oeorse Will 

2 Anyvthere, Modtson. 
Wl. 53705 

Credit Card: 

Buyl JlleverMind 




Final HTTP transaction sent to server: 

POST / /cgi -bin/purchase 

name/George Will 

screec/2 Anywhere 

ci cy /Madison 

scace/WI 

zip/53705 

ca rdc yoe / visa 

cnun\t)er/7 7 32222 15 6561000 

buy /Buy! 





FIG. 18b 
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HTMLp 



Result 



cHEAO> 

<TITLE>Green-Tonqued Iguana</T1TLE> 

c/he:ad> 
<BO0Y> 

The <A href-iguana . qlf label- Picturogrecn-tongucd iguana</a> is a 
naclve of <a href-aiap?ca.cy-»adclaide label-map>AdeIaide . 
Australia</a>. 2c likes co live ur.<ier spare cires, unlike che <a 
href •lizards /blue *-congued -iguana . hcnLl>Biue'Tongued Iguana </a>, its 
cousin cc rhe north. 
</BO0y> 



-on , 



[Trio green- lonoug?^ 
^^Mono a o notrwe oi 
I AaetojOc. Auir/otta . If 
PiKei 10 iveLr^r spore 
jtvet.iniM the 

L f s cou« n f o inc nor in. 
t j ImU 



Gf ew- Twwucfl Iquono 



ne yeen»»ongueq 
'^■Jor'O ixonotfx/eoi 



FIG. 19 
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HTMLp 

<HEAD> 

<TITLE>OAK to StA 3/24</TirLE> 

'<LINKMENU> 

</he:ad> 

<BODr> 

<TABLE> 

<TR> 

<TK><U>riigr»t</U></TH> 

<TH ALICl*-CEKTEP><U>Oep</U></TH> 

<TH ALICll-CENTER><U>Arr</0></TH> 

</TR> 

<TR> 

<TD><A HR£r-flight$/ua909.htna>UA 909</A></T0> 

<TO ALIG1I»RICHT>09:33</TD> 

<TO Al*ICN«RIGHT>llt22</TD> 

</TR> 

<TR> 

<TD><A HREr-fli9hcs/as63.html>AS 63</A></TO> 

<TD ALICN»RIGHT>10:02</TD> 

<TD ALIGN»R1GHT>11:57</TD> 

</TR> 

<TR> 

<TD><A HR£r-fiigrit5/asl02.html>AS 102</a></T0> 

<TO ALIGN-RIGHT>12:36</TD> 
<TD ALIGN-RIGHT>14:08</TD> 
</TR> 

<TD><A HR£r«fiigftCS/uaBB7.htna>UA 8e7</A></TD> 

<TD ALICN-RICHT>15:10</TO> 

<TD ALICN-RIGHT>l"»:2l</TO> 

</TR> 

</TABLE> 

</BODY> 



Result 

A5S3 OjC2 lt57 
AS 102 1236 H:08 
UA887 &« 17:21 

t»Ktct t 
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Barbra 



lire b txity 



(b) 



BOf A 



comectr>9.^ 



(c) 



16S5S52373W0806595 
BOf A 

r 



BOf a" 
r 



(e) 



FIG. 21 



Barbra 
ft 



AC1IV1 em 



(a) 



— Of*nOLDO0:2 

-ACTIVC 00C03 - 
» Carm 



(b) 



123 



^ON^K)a> 0054 — 
-ACTlVf 00:45 



► OC«fi«rf«fic«( 
•Mow I 



(c) 



FIG, 22 
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HTMLp 


Result 


<KTMl-> 
<HEJID> 




<TITL£>£rror-' <yTITI*E> 

<KEY KEY-1 LABEL--Sorry ♦ " ACTION-pop> 

</HEAD> 

<BOOY> 

<ci:nter> 

<IMG SRC«fiIe : //booboo.gif > 

<BR> 

<B><rONT SI2E»*?><INC SRC-cxcra :me3sa9e></FOMT></B> 

</CENTER> 

</BODY> 

</HTMI.> 














Please enter a 
valid phone 
number 

Sony! i 





FIG. 23 
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Keycaps 


Miscellaneous 


builcm:keyl 


O 


builtin.'smiley 


© 


builrin:kcy2 




builria.signai 




builtin:key3 ^ 






buihin:kcy4 


o 






bujltinikcyS 








buiitin:key6 








builtin:kcy7 q 






builtinikeyS ^ 






bailtin:kcy9 








buiUin:kcyO 






PHo^E Number Types 


buiitinitypcO 




buiiiinibigrypcO 




builtinztypci 


A 


builtin:bigrype 1 




builnn:type2 




builtin:bigtypc2 




bujltin:rype3 


i 


bui!lin:bigtypc3 




builiin:cypc4 




buillin:bigtypc4 




builtin:type5 




bui!tin:bigcypc3 




builtm:type6 




buiitin:bigiypc6 




builiin:rypc7 g 


builiin:bigtype7 


Id) 
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HTMLp 



Result 



<HEAO> 

<OIAl* KAME^-Voice Mail- NOSCREENCHANGB>8H4295xl4«16722</0IAL> 

<TITLE>Vovce Boxc/TITt.E> 

<KEY kz:y-«5 action- vmLiac en. hcp> 

<KEV KEY-14 ACTION-vmGreccing.hcpJ' 

<KI:y KEY-t6 ACTION-VTnNew.hcp> 

<KEY KCY-19 ACTION-vmSa9noCf ,hcp> 

<XEY KEY-de£ault ACTION-none> 

<TOP> 

</he:ad> 

<IMC SRC-buiXcin://)cey4> Creecxng Opcions<br> 
<IMC SRC-buLlcin: //lcey5> Listen co Hessa9es<br> 
<IMG SRC-builtin: //key6> Record a Me3sa9e<bc> • 
<IMG SRC-Duxltm: //Xey9> Sign or£<bc> 

</BQDY> • 



O^cetrk^Optcru 
9 L it len Me: ro9et 

O Sign Off 



<HEAD> 

<OrAL>5</OIAL> . - • 

<TrTLE>Lxst:en</TITLE> 

<KEY KEY-12 ACTION-pMonc :dial ?nuin-2> 

<KEY KEY-13 ACTION-pnone :dial?nun\-3> 

<KEY KEY«f5 ACTICN-phonc :dial ?najn-5> 

<KEY KEY-17 ACTION-phone :dial ?najn-7> 

<KEY KEY-f9 ACTION-pop> 

</HEAD> 

<BODY> 

<rMC SRC-buillin: // Jtey2 wlDTH-22> Back Up a Bic<br> 

<rMG SRC»buiitin: //Jcey2><IMG S RC-builcin : //Jcey2> Scirt Agaxn<br> 

<IMC SRC-bci* cm: //key3 WlOTK-22> Ec-ie<bc> 

<IMC SRC-bcilirn: //XeyS WI0TK-22> Next Mejsage<br> 

<IMG SRC-buil:ir.://lcey7 WlDTH-22> Save Messa9c<bir> 

<rMC SRC-buil-in://Key9 WlDTK-22> Scop Liscening<t>r> 

</BODY> 











^•StarlAaan 


# 


£ra>a 




MeztMe3i09tt 


« 




o 


Sloolaienns 
1 



FIG. 25 
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